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1.  EXECUTIVE  SUMMARY 

1.1  Purpose 

The  purpose  of  this  effort  was  to  develop  an  execution  plan  for  improving  the  strategic 
environment  (SE)  for  the  U.S.  Army  modeling  and  simulation  (M&S)  community.  The  plan’s 
focus  time  frame  is  through  the  U.S.  Government  fiscal  year  (FY)  03.  The  study  used  the 
definition  of  the  SE  from  the  DoD  and  Army  Model  and  Simulation  Master  Plans: 

Intemetted  simulations  that  represent  activities  at  a  high  level  of  realism  from  simulations 

of  theaters  of  war  to  factories  and  manufacturing  processes.  These  environments  may  be 

created  within  a  single  computer  or  a  vast  distributed  network  connected  by  local  and  wide 

area  networks  and  augmented  by  super-realistic  special  effects  and  accurate  behavior 

models.  They  allow  visualization  of  and  immersion  into  the  environment  being  simulated. 

The  synthetic  environment,  therefore,  is  a  highly  inclusive  concept  that  consists  of: 

•  the  synthetic  natural  environment  (terrain,  oceans,  atmosphere,  and  space) 

•  the  equipment  used  to  build  the  SE  (computer  hardware,  communication  devices,  networks, 
vehicle  simulators,  display  devices) 

•  software,  databases,  and  tools  for  designing,  setting  up,  executing,  and  monitoring  tests  and 
experiments  and  for  analyzing  the  results. 

It  can  even  include  live  participants,  when  they  function  as  role  players.  It  is  this  broad  definition 
of  the  synthetic  environment  that  is  used  throughout  this  report. 

1.2  Approach  Taken 

The  approach  taken  was  to  determine  the  synthetic  environment  status  and  needs  from: 

•  DoD  and  U.S.  Army  M&S  policies,  master  plans,  investment  plans,  and  vision  statements 

•  Interviews  with  a  wide  variety  of  senior  DOD  and  U.S.  Army  officials  who  are 
knowledgeable  about  and  involved  in  various  aspects  of  M&S  policy,  oversight, 
specification,  development,  and  use 

•  Other  M&S  professionals  identified  through  research  documents,  reports,  and  referrals. 

The  inputs  from  these  sources  were  consolidated  into  categories  of  issues.  In  parallel,  enabling 
technologies  were  identified  that  can  be  applied  toward  solving  the  issues.  Finally,  approaches  to 
solving  each  of  the  identified  issues  were  defined  and  documented. 

1.3  Findings 

Seven  categories  of  SE  issues  were  identified  and  prioritized.  The  top  category  was  synthetic 
natural  environment  issues,  especially  problems  relating  to  building  and  using  terrain  databases. 
The  need  for  better  representation  of  the  behaviors  of  individuals,  vehicles  with  crews,  units,  and 
commanders  and  their  staffs  was  the  number  two  category.  The  third  category  was  the  need  for 
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better  interoperability  between  simulators.  Fourth  was  the  need  for  multipurpose,  reconfigurable 
simulators.  Better  communications  network  models,  and  interfacing  between  C4I  systems  and 
the  SE  were  fifth.  Sixth  was  the  need  for  more  entities,  to  simulate  larger  fights  between  more 
diverse  units.  The  remaining  category  was  tools  to  make  it  faster  and  easier  to  build  the  SE, 
design  and  set  up  experiments,  collect  data,  and  analyze  results. 

Eight  categories  of  enabling  technologies  were  identified  as  being  particularly  relevant  to 
developing  an  improved  SE.  They  were  architectures,  computers,  display  devices,  display 
generators,  man  machine  interface  devices,  networks,  software,  and  tools. 

1.4  Solution  Approaches 

Execution  plans  were  defined  and  documented  for  applying  each  enabling  technology  toward 
solving  the  SE  issues.  To  effectively  implement  these  plans  probably  requires  a  staff  of  technical 
experts  who  report  to  a  manager  who  is  above  the  Program  Managers.  Someone  at  that  level  is 
needed  to  make  and  enforce  decisions  that  may  impact  one  program  negatively,  but  are  best  for 
the  programs  as  a  whole. 

Execution  plans  were  defined  and  documented  for  addressing  each  of  the  SE  issues. 
Implementing  these  plans  must  be  accomplished  within  the  business  environment  that 
STRICOM  operates.  This  will  involve  tradeoffs  among  the  priority  assigned  by  higher  level 
commanders,  the  estimated  cost,  funding  availability,  the  potential  benefit,  the  urgency  of  the 
time  frame,  and  the  development  risk. 

1.5  STRICOM  SE  Leadership  Opportunities 

The  existence  of  these  SE  issues  presents  an  opportunity  for  STRICOM  to  provide  the  leadership 
to  solve  them  for  the  benefit  of  the  Army  M&S  community.  To  accomplish  this,  STRICOM  must 
address  five  factors: 

1.  Implementing  the  solutions  will  require  an  appropriate  pool  of  skilled  technical  people. 
When  there  are  identified  solution  approaches,  the  technical  risk  is  low. 

2.  Funding  must  be  found  to  implement  each  solution.  Since  the  problems  needing  to  be  solved 
span  all  three  domains,  the  possibility  exists  to  solicit  and  pool  resources  from  a  number  of 
organizations.  Also,  a  pricing  strategy  is  needed  which  allows  STRICOM  to  earn  profits  on 
the  programs  it  executes.  This  profit  would  become  working  capital  and  investment  capital. 
This  is  a  normal  practice  in  all  businesses. 

3.  An  organizational  structure  is  needed  within  STRICOM  that  will  encourage,  facilitate,  and, 
when  necessary,  enforce  cooperative  developments  and  reuse  across  its  projects. 

4.  A  contractual  mechanism  is  needed  between  STRICOM  and  the  program  funding 
organizations  that  will  allow  STRICOM  to  earn,  use,  and  invest  profits. 

5.  Develop  strategic  alliances  with  key  government  and  industry  organizations. 

A  broader  leadership  opportunity  would  be  to  move  beyond  a  focus  on  training  simulators  and 
seek  to  provide  a  common  SE  and  common  applications  across  all  three  domains:  ACR,  RDA, 
and  TEMO.  The  broadest  leadership  opportunity  is  to  provide  well-organized,  high  quality 
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leadership  to  the  entire  M&S  community,  and  target  becoming  the  Simulation  Center  for  the 
Army. 
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2.  INTRODUCTION 

2.1  Objectives 

There  were  two  contractual  objectives  for  this  study  effort.  The  first  was  to  provide  analysis  and 
data  for  a  plan  to  guide  the  direction  of  the  synthetic  environment  (SE)  development  through  the 
POM  98-03.  The  second  was  to  provide  STRICOM  with  a  mid  and  long-range,  high  level 
strategic  plan  for  synthetic  environment  development  and  execution. 

Research  and  data  gathering  were  conducted  to  help  identify  the  Army's  major  SE  needs  for  FY 
98-03.  That  information  was  analyzed,  consolidated,  and  prioritized  within  the  constraints  of  the 
study.  Completion  of  that  activity  fulfilled  the  first  objective.  Plans  were  then  generated  for  how 
to  meet  each  of  the  identified  major  SE  needs.  These  plans  are  documented  in  this  report  and  are 
also  summarized  in  a  companion  viewgraph  presentation.  Completion  of  that  activity  fulfilled 
the  second  objective. 

2.2  Methodology 

To  put  the  project  into  a  proper  organizational  context,  the  first  step  taken  was  to  acquire  and 
study  the  U.S.  Army  models  and  simulations  (M&S)  management  policies,  master  plans, 
investment  plans,  and  vision  statements. 

The  next  step  was  to  determine  the  Army's  SE  needs  for  FY  98-03.  This  information  was  not 
contained  in  the  documents  that  had  been  examined.  The  strategy  chosen  was  to  interview  a  wide 
variety  of  key  senior  DoD  and  U.S.  Army  officials  who  are  knowledgeable  about  and  involved  in 
various  aspects  of  M&S  policy,  oversight,  specification,  development,  and  use.  A  list  of  such 
people  was  compiled  and  refined  with  assistance  from  The  U.S.  Army  Simulation,  Training,  and 
Instrumentation  Command  (STRICOM).  A  letter  was  then  sent  by  STRICOM  to  each  identified 
official,  requesting  their  participation  in  a  short  telephone  interview.  A  list  of  sample  questions 
was  enclosed  with  the  letter.  Each  proposed  interviewee  was  then  telephoned  to  request  a 
specific  time  to  conduct  the  interview.  The  interviews  were  conducted  over  a  six-week  period, 
beginning  in  late  January,  1998.  During  that  time,  the  initial  list  of  people  to  interview  was 
expanded  from  information  in  research  documents,  reports,  the  M&S  master  plans,  and  from 
referrals. 

The  respondents  were  very  cooperative  and  provided  valuable  insights  and  information.  Their 
inputs  were  consolidated  into  categories  of  issues.  The  issues  were  prioritized  based  on  the 
approximate  number  of  people  who  mentioned  the  issue.  In  this  report,  the  inputs  have  not  been 
identified  with  particular  respondents.  We  planned  to  keep  the  comments  anonymous,  believing 
it  was  important  to  encourage  the  respondents  to  be  candid. 

In  parallel  with  conducting  the  interviews  and  beginning  to  identify,  consolidate,  and  prioritize 
the  SE  issues,  a  number  of  additional  relevant  documents  were  examined.  Writing  of  this  report 
began  while  the  interview  process  was  still  underway.  When  enough  information  had  been 
acquired  to  identify  and  clarify  a  topic,  a  preliminary  draft  of  the  corresponding  subsection  was 
written.  Those  drafts  were  updated  as  additional  relevant  information  was  obtained. 
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2.3  Organization  of  the  Report 

The  report  is  organized  as  follows:  Section  1  discusses  the  objectives  and  describes  the 
methodology  used  in  this  study.  Section  2  establishes  the  synthetic  environment  context  by 
providing  a  brief  history  of  Army  M&S  and  a  definition  of  the  synthetic  environment.  An 
overview  of  what  can  be  modeled  in  the  SE,  the  SE  issues  which  were  identified,  and  the 
enabling  technologies  which  can  help  address  those  SE  issues  are  presented  in  Section  3.  Section 
4  discusses  the  STRICOM  business  context,  describes  actions  to  take  advantage  of  the  enabling 
technologies,  and  contains  plans  for  addressing  the  SE  issues.  Section  5  summarizes  the  findings 
and  methods  to  begin  implementing  the  execution  plans.  A  copy  of  the  letter  introduction  from 
STRICOM  to  each  proposed  interviewee  is  contained  in  Appendix  A.  Appendix  B  is  a  list  of  the 
names,  organizations,  addresses,  and  phone  numbers  of  the  interviewees.  Appendix  C  is  a  list  of 
the  referenced  documents.  Appendix  D  is  a  glossary  of  acronyms. 
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3.  SYNTHETIC  ENVIRONMENT  CONTEXT 
3.1  Framework  of  Army  Modeling  and  Simulation 

This  section  includes  a  brief  history  of  U.S.  Army  Modeling  and  Simulation  (M&S).  The 
synthetic  environment  is  defined.  Three  viewpoints  of  the  SE  -  operational,  system  or  program, 
and  technical  are  explained. 

Prior  to  1990,  the  field  of  M&S  was  marked  by  fragmentation  and  limited  coordination  of 
activities  across  key  communities,  e.g.,  across  Service  lines  and  across  functional  areas. 
Recognizing  these  problems,  Congress  directed  the  Department  of  Defense  (DoD)  to  "... 
establish  an  Office  of  the  Secretary  of  Defense  (OSD)  level  joint  program  office  for  simulation 
to  coordinate  simulation  policy,  to  establish  interoperability  standards  and  protocols,  to  promote 
simulation  within  the  military  departments,  and  to  establish  guidelines  and  objectives  for 
coordination  of  simulation,  wargaming,  and  training"  (Senate  Authorization  Committee  Report). 
The  Defense  Modeling  and  Simulation  Office  (DMSO)  was  subsequently  established  to  be  that 
organization. 

In  1991,  the  Deputy  Secretary  of  Defense  assigned  overall  management  responsibility  of  all  DoD 
M&S  to  the  Under  Secretary  of  Defense  for  Acquisition.  This  office  established  the  DoD 
Executive  Council  on  Modeling  and  Simulation  (EXCIMS)  who  developed  a  vision  for  DoD 
M&S.  This  vision  was  intended  to  help  focus  the  DoD's  M&S  community  on  its  core  functions 
and  to  focus  on  applications  that  would  enhance  overall  M&S  capability. 

These  ideas  were  incorporated  by  the  EXCIMS  into  the  DoD  M&S  vision: 

1 .  Defense  modeling  and  simulation  will  provide  readily  available,  operationally  valid 
environments  for  use  by  the  DoD  Components: 

a.  To  train  jointly,  develop  doctrine  and  tactics,  formulate 

b.  operational  plans,  and  assess  warfighting  situations. 

c.  To  support  technology  assessment,  system  upgrade,  prototype  and  full-scale 
development,  and  force  structuring. 

2.  Furthermore,  common  use  of  these  environments  will  promote  a  closer  interaction 
between  the  operations  and  acquisition  communities  in  carrying  out  their  respective 
responsibilities.  To  allow  maximum  utility  and  flexibility,  these  modeling  and  simulation 
environments  will  be  constructed  from  affordable,  reusable  components  interoperating 
through  an  open  system  architecture. 

Four  major  trends  have  established  the  conditions  for  the  current  status  of  Army  M&S 
management: 

•  First,  the  continuing  revolution  in  information  technologies  has  widened  the  opportunity  for 
using  M&S,  often  enabling  organizations  to  use  M&S  developed  by  others.  This  has 
increased  the  number  of  users  of  Army  M&S  to  the  point  that  M&S  are  ubiquitous,  touching 
almost  all  aspects  of  Army  operations. 
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•  Second,  this  same  technology  revolution  has  engendered  an  infrastructure  that  permits 
greatly  increased  sharing  of  M&S  among  distant  developers  and  users. 

•  Third,  the  current  trend  of  increased  budgetary  constraints  has  emphasized  the  need  for  more 
effective  and  efficient  development,  use,  and  sustainment  of  Army  M&S. 

•  Finally,  the  evolution  towards  the  Army  as  part  of  a  Joint  force  has  energized  the  need  to 
ensure  Army  M&S  can  interoperate  with  other  Service  and  Department  of  Defense 
capabilities. 

In  response  to  the  challenges  created  by  these  trends,  the  Army  leadership  created  a  new 
management  structure  for  Army  M&S  that  includes  the  Army  Model  and  Simulation  Office 
(AMSO)  as  the  central  management  office  for  M&S.  The  AMSO  is  part  of  the  overall  M&S 
management  structure  now  in  place  to  focus  M&S  investments  more  efficiently.  The  vision  for 
the  M&S  community  is  promulgated  by  the  Army  Model  and  Simulation  Executive  Council 
(AMSEC)  and  the  AMSO  with  the  three  domain  managers.  The  Army  manages  M&S  by 
domains  based  on  functional,  rather  than  organizational  lines.  The  three  domains  are:  Advanced 
Concepts  and  Requirements  (ACR),  Research,  Development  and  Acquisition  (RDA),  and 
Training,  Exercises  and  Military  Operations  (TEMO). 

3.1.1  Army  M&S  Domains 

Each  of  the  three  domains  established  supporting  structures  to  guide  their  investments.  Each 
domain's  plans  outline  its  approach  to  meeting  the  strategic  level  guidance.  Together,  the 
strategic  guidance  and  domain  supporting  guidance  establish  the  general  direction  for  M&S 
investments  across  the  Army  and  within  each  domain.  All  Army  M&S  activities  fall  either  under 
the  purview  of  a  single  domain  or  are  cross-domain  activities.  The  example  activities, 
simulations,  and  simulators  listed  in  Table  1  are  predominately  used  in  the  corresponding 
domain,  but  are  by  no  means  exclusive  to  that  domain.  Individual  organizations  determine  the 
proper  domain(s)  for  their  requirements. 

Table  1.  The  Army's  M&S  Domains  with  Example  Activieies  and  Systems 


Domain 

Domain  Activities 

Simulations/Simulators 

Advanced  Concepts  and 
Requirements  (ACR) 

Force  Planning 
Developing  Requirements 
Warfighting  Experiments 

Reconfigurable  Simulators 
Constructive  Models 

Research,  Development, 
and  Acquisition  (ACR) 

Basic/Applied  Research 
Weapons  System 
Development 

Test  and  Evaluation 

System  Prototypes 
Engineering  and  Physics 
Models 

Training,  Exercises,  and 
Military  Operations 
(TEMO) 

Individual  and  Collective 
Training 

Joint  and  Combined 
Exercises 

Mission  Rehearsal 
Operations  Planning 

System  Simulators 
Training  Simulations 
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3.1.1. 1 ACR  Domain 

The  ACR  domain  supports  the  Institutional  Army's  core  capabilities  of  Direct  and  Resource  the 
Force  and  Develop  the  Force.  The  principal  focus  of  the  ACR  domain  is  providing  strategic 
direction,  concept  development,  requirements  development,  and  force  planning.  ACR  domain 
activities  depend  upon  insights  and  quantitative  data  from  M&S  for  analyzing  strategic, 
operational,  and  tactical  operations  in  war,  conflict,  and  operations  other  than  war.  The  primary 
products  of  these  activities  are  strategies,  warfighting  concepts,  mission  needs,  doctrine, 
requirements,  executable  plans,  and  affordable  programs. 

The  ACR  domain  addresses  four  analytical  categories  where  M&S  is  significant:  strategic  and 
operational  force  analysis,  tactical  force  analysis,  modernization  analysis,  and  other  unique 
analysis.  They  have  established  five  domain  objectives  for  the  FY  98-03  POM: 

1 .  Using  M&S  as  a  primary  tool,  validate  Army  operational  requirements,  structure,  and 
doctrine  at  strategic,  tactical,  and  entity  levels. 

2.  Support  acquisition  reform  and  participation  in  Integrated  Concept  Teams  to  define  Mission 
Needs  Statements  and  Operational  Requirements  Documents. 

3.  Assess  C4I  requirements  and  integrate  simulations  and  proven  C4I  systems  for  a  multi- 
echeloned  digitized  force. 

4.  Network  key  M&S  capabilities  to  support  existing  and  proposed  major  weapon  systems 
developments  in  a  common  synthetic  environment  for  Force  XXI. 

5.  Support  cost,  production,  and  maintenance  assessment  for  joint  warfighting  capabilities. 
Support  development  and  implementation  of  the  Joint  Warfare  System  (JWARS). 

3. 1.1.2  RDA  Domain 

The  RDA  domain  supports  the  Institutional  Army's  core  capability  of  Sustain  the  Force.  The 
principal  focus  of  the  RDA  domain  is  supporting  research,  development,  system  acquisition,  and 
logistical  support,  plus  advancing  the  art  and  science  of  the  Army's  M&S  across  all  domains. 

The  RDA  M&S  applications  run  the  gamut  from  highly  detailed  analysis  of  physics  based 
characteristics  of  the  proposed  system  to  less  detailed  analysis  of  applications  of  emerging 
technologies.  RDA  uses  models  and  simulations  to  support  their  missions  of  research  and 
development,  system  acquisition,  test  and  evaluation,  and  logistical  support,  as  well  as  to 
advance  the  state  of  the  art  of  the  models  and  simulations  used  in  all  three  domains.  Their  M&S 
objective  is  to  provide  support  for  the  four  elements  which  make  up  the  RDA  effort:  major 
systems  (Acquisition  Category  I  and  II  programs),  science  and  technology  programs  (Advanced 
Technology  Demonstrations  and  Advanced  Concept  Technology  Demonstrations),  test  and 
evaluation  programs,  and  non-major  systems  (Acquisition  Category  III  programs). 

3.1. 1.3  TEMO  Domain 

The  TEMO  domain  supports  the  Institutional  Army's  core  capabilities  of  Develop  the  Force, 
Generate  and  Project  the  Force,  and  Sustain  the  Force.  The  principal  M&S  focus  of  TEMO  is 
providing  capabilities  that  support  the  maintenance  of  a  trained  and  ready  force.  TEMO  domain 
activities  include  individual,  crew,  and  collective  training  events  and  M&S  support  to  military 
operations  at  the  tactical  and  operational  levels  using  a  variety  of  networked  and  stand-alone 
live,  virtual,  and  constructive  M&S  capabilities. 
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The  TEMO  domain  uses  the  SE  to  support  training,  exercises,  and  mission  rehearsal  to  prepare 
the  commanders,  soldiers,  and  units  of  the  Army  for  quick,  effective  and  joint  responses  to 
worldwide  contingencies.  The  TEMO  M&S  objectives  are: 

1 .  Support  the  Army ’  s  training  architecture, 

2.  Manage  the  development  and  fielding  of  Training  Aids,  Devices,  Simulators,  and 
Simulations  (TADSS),  and 

3.  Ensure  an  M&S  infrastructure  is  embedded  into  future  training  systems  to  support  training, 
mission  rehearsal,  and  operations  planning. 

All  three  domains  need  and  use  synthetic  environments  to  support  their  missions.  It  is 
noteworthy,  therefore,  that  none  of  the  domains  has  the  responsibility  for  an  objective  to 
develop,  maintain,  or  make  available  to  itself  and  others  the  core  infrastructure  of  the  SE.  This 
could  be  one  of  the  reasons  that  it  is  difficult  to  fund  and  to  perform  this  task.  To  proactively 
seek  a  solution  to  this  is  a  natural  role  for  STRICOM. 

3.1.2  Army  M&S  Masterplans 

The  Army  Modeling  and  Simulation  (M&S)  Master  Plan  (1995)  and  The  DoD  M&S  Master  Plan, 
1996  define  six  fundamental  objectives  which  form  a  framework  for  the  Army  M&S 
infrastructure  and  a  foundation  for  Army  M&S  development.  These  objectives  address  the 
technical  groundwork  aspects  needed  to  ensure  commonality  and  foster  interoperability  of  Army 
M&S.  These  fundamental  objectives  apply  to  each  domain  and  address  primarily  how  M&S 
should  be  developed: 

Objective  1 :  Provide  a  common  M&S  technical  framework 

Objective  2:  Provide  timely  and  authoritative  environmental  representations 

Objective  3:  Provide  authoritative  representations  of  systems 

Objective  4:  Provide  authoritative  representations  of  human  behavior 

Objective  5:  Provide  an  M&S  infrastructure  to  meet  developer  and  end-user  needs. 

Objective  6:  Share  M&S  benefits 

These  Army  and  DoD  M&S  objectives  form  a  framework  for  M&S  investment  planning  and 
support  the  achievement  of  domain  M&S  objectives.  The  1995  Army  M&S  Master  Plan 
establishes  a  process  for  developing  technical  M&S  standards  to  meet  fundamental  Army  M&S 
objectives.  This  standards  development  process,  which  has  now  been  underway  for  several  years, 
builds  technical  M&S  procedures,  algorithms,  and  other  appropriate  M&S  techniques,  and 
increases  commonality  and  reuse  potential.  As  the  standards  are  developed,  the  Army  moves 
progressively  closer  to  achieving  the  Army  and  DoD  objective  M&S  environment. 

Investment  in  M&S  provides  a  critical  underpinning  for  a  variety  of  Army  missions  from 
designing  a  future  force  and  building  the  systems  and  doctrine  for  that  force,  to  training  and 
operating  that  force.  Careful  planning  for  M&S  resources  enables  organizations  throughout  the 
Army  to  benefit  from  each  others'  expertise  and  products,  while  minimizing  duplication. 

The  second  edition  of  The  Army  M&S  Master  Plan  (1995)  presented  the  Army's  plan  for 
embracing  the  power  of  Distributed  Interactive  Simulations  (DIS).  In  the  three  years  since  the 
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publication  of  that  plan,  significant  changes  have  occurred  in  the  M&S  community.  The 
standards  for  the  DoD  common  technical  framework,  most  notably  the  High  Level  Architecture 
(HLA),  began  supplanting  the  DIS  standards  for  interoperability.  The  leadership  of  the  Army 
strengthened  the  management  roles  of  the  domains.  Changes  also  occurred  in  the  broader 
community  served  by  M&S.  The  publication  of  Joint  Vision  2010  and  Army  Vision  2010 
established  new  concepts  and  a  new  lexicon  for  describing  future  capabilities.  The  Army  After 
Next  program  started  to  investigate  the  major  factors  that  will  affect  the  Army  in  the  years  2010- 
2025.  As  each  of  these  changes  shed  more  light  on  the  Army's  future,  they  present  new 
challenges  for  the  M&S  After  Next. 

3.2  Synthetic  Environment  Defined 

Both  the  DoD  M&S  Master  Plan,  1996  and  the  Army  M&S  Master  Plan,  1997  have  the 
following  definition  for  the  synthetic  environment: 

Intemetted  simulations  that  represent  activities  at  a  high  level  of  realism  from  simulations 
of  theaters  of  war  to  factories  and  manufacturing  processes.  These  environments  may  be 
created  within  a  single  computer  or  a  vast  distributed  network  connected  by  local  and 
wide  area  networks  and  augmented  by  super-realistic  special  effects  and  accurate 
behavior  models.  They  allow  visualization  of  and  immersion  into  the  environment  being 
simulated. 

Thus  the  synthetic  environment  is  a  highly  inclusive  concept.  It  includes  the  synthetic  natural 
environment  (terrain,  oceans,  atmosphere,  and  space).  It  includes  the  equipment  used  to  build  the 
SE  (computer  hardware,  communication  devices,  networks,  vehicle  simulators,  display  devices). 
It  includes  the  software,  databases,  and  the  tools  for  designing,  setting  up,  executing,  and 
monitoring  tests  and  experiments  and  for  analyzing  the  results.  It  can  even  include  live 
participants  when  they  function  as  surrogates  or  role  players.  It  is  this  broad  definition  of  the 
synthetic  environment  that  has  been  used  throughout  this  report. 

Figure  1  illustrates  this  definition  of  the  synthetic  environment  as  it  applies  to  Army  models  and 
simulations.  Four  of  the  blocks  in  the  center  of  the  figure  represent  the  major  types  of  military 
entities  in  the  synthetic  environment:  Command,  Control,  Communication,  Computers,  and 
Intelligence  (C4I)  systems,  Vehicles  on  test/training  ranges  (live),  Semi- Automated  Forces 
(SAF)  and  Manned  Simulators  (virtual),  and  simulations  consisting  of  Computer  Generated 
Forces  (CGF)  and/or  Semi-Automated  Forces  (constructive).  They  send  and  receive  control 
information,  data,  voice,  video,  and  interactions  through  the  interconnections  function. 

At  the  top  of  Figure  1  are  shown  the  support  functions.  These  facilitate  the  design,  setup, 
execution,  and  monitoring  of  tests,  exercises,  and  experiments.  They  also  provide  for  data 
collection,  and  they  support  After  Action  Reviews  (AAR)  and  analyses.  At  the  bottom  of  the 
figure  the  live  participants  are  shown.  Some  of  these  may  be  surrogates  or  role  players.  Others 
could  be  operators,  controllers,  users,  trainees,  developers,  experimenters,  observers,  or  analysts. 
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Figure  1.  Top  Level  Block  Diagram  of  the  Synthetic  Environment 


3.3  Three  Perspectives  of  the  Synthetic  Environment 

Because  of  differences  in  their  areas  of  responsibility,  each  organization  within  the  Army  has 
different  areas  of  interest  relative  to  the  synthetic  environment.  This  results  in  a  variety  of 
perspectives  of  the  SE.  This  report  considers  three  such  perspectives:  the  operational  perspective, 
the  system  or  program  perspective,  and  the  technical  perspective. 

3.3.1  Operational  Perspective 

The  Operational  perspective  is  that  of  the  users  of  the  synthetic  environments.  These  include 
commanders  of  forces  at  various  echelons,  the  staff  who  provide  information  to  them,  battle 
laboratory  directors,  researchers,  analysts,  instuctors,  and  trainers.  Their  concern  is  about  which 
aspects  of  the  operational  forces  and  the  environment  can  and  cannot  be  represented  in  the  SE. 

Of  those  aspects  represented,  they  are  concerned  about  how  well  they  can  be  represented. 

Within  the  Army,  different  organizations  have  their  own  areas  of  responsibility,  and  utilize 
synthetic  environments  in  different  ways  to  help  meet  those  responsibilities.  Because  of  these 
differing  perspectives,  various  organizations  have  their  own  view  of  the  capabilities,  limitations, 
and  shortfalls  of  the  SE. 

Those  with  the  operational  perspective  often  do  not  understand  or  appreciate  that  requiring 
specific  capabilities  in  a  synthetic  environment  affects  the  cost,  schedule,  and  complexity  of  the 
systems  that  comprise  that  SE. 
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3.3.2  Systems  or  Program  Perspective 

The  Systems  or  Program  perspective  is  that  of  program  managers  and  systems  engineers  who  are 
responsible  for  particular  programs,  i.e.,  SAFs,  CGFs,  and  manual  simulators.  Their  focus  is  on 
the  required  capabilities  of  their  particular  system  and  on  the  system's  role  in  the  SE.  They  are 
concerned  about  the  definition  of  the  system  interfaces,  the  information  needed  from  the  SE,  the 
information  which  must  be  provided  to  the  SE,  how  that  can  be  made  to  happen,  and  the 
resulting  capability  of  the  system  when  operating  in  the  SE.  They  view  their  system  as  a  task 
which  must  be  accomplished  within  the  confines  of  its  requirements,  schedule,  and  funding. 
Program  managers  often  do  not  understand  the  ramifications  that  system  design  decisions  will 
have  later  on  the  ease  or  difficulty  of  using  the  system,  of  making  modifications  and 
enhancements,  and  of  its  reuse  by  others. 

3.3.3  Technical  Perspective 

The  Technical  perspective  is  that  of  the  Army  and  contractor  design  engineers  who  are  tasked 
with  implementing  and  integrating  the  pieces  which  comprise  either  a  particular  system  or  a 
synthetic  environment.  They  view  the  system  and  the  SE  as  consisting  of  its  constituent  parts 
(e.g.,  computers,  software,  object  models,  data  representations,  operator  controls,  display 
devices)  and  their  interconnections  (e.g.,  interfaces,  communication  devices,  networks).  They  are 
very  much  interested  in  the  technological  advances  that  can  provide  the  means  to  build  a  better 
system,  enhance  the  capabilities  of  existing  systems,  or  improve  the  overall  synthetic 
environment.  They  often  do  not  understand  the  ramifications  that  including  or  not  including 
specific  technical  capabilities  has  on  users  in  the  operational  domains. 

There  is  a  need  for  coordination  and  cooperation  among  the  operational  users,  the  program 
managers,  and  the  technical  implementers.  Fostering  and  facilitating  this  is  a  natural  role  for 
STRICOM. 
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4.  FINDINGS 

This  section  defines  what  can  be  modeled  in  the  synthetic  environment,  identifies  the  SE  issues 
that  must  be  solved  to  achieve  significant  improvements  in  the  current  state-of-the-art,  and 
identifies  the  enabling  technologies  that  support  developing  those  solutions. 

Table  2.  Framework  For  What  Can  Be  Modeled 


Time 

Frame 

Applications 

Scope 

Force 

Type 

Echelon 

Phases  of 

Operation 

Elements  To  Be 

Modeled 

Current 

(TEMO) 

Emerging, 

Visionary 

(ACR, 

RDA) 

Analytic 

Applications 

Doctrine 

Training 

Leader 

Development 

Organization 

Materiel 

Soldiers 

Army 

Joint 

Coalition 

Opposing 

Force 

Theater 

Vehicle 

Soldier 

Force  Projection 
Cycle 

Alert 

Mobilization 

Early  Entry 
Operations 

Operations 

Sustainment 

Recovery 

Redeployment 

Peacetime 

Sustainment 

Vehicles 

Units 

Forces  (Collections  of 
Units) 

C4I 

Tactics  and  Behaviors 

Battlefield  Environment 
(SNE) 

Terrain 

Weather 

Manmade  Objects 
Weapons  Effects 
Countermeasures 
Effects 

Specific  Locations 
(Identification  of 
Battlespace) 

4.1  What  Can  Be  Modeled 

It  is  not  possible  to  know  exactly  what  the  Army  will  be  required  to  model  and  simulate  in  the 
synthetic  environment  from  FY  98  -  FY03.  It  is  not  possible  to  know  exactly  who  or  how  the 
Army  will  be  required  to  fight.  Due  to  these  two  unknowns,  it  is  not  possible  to  know  exactly 
what  new  military  operations  require  research  and  development,  analysis,  or  training.  In  spite  of 
these  unknowns,  it  is  possible  to  state  the  likely  M&S  capabilities  that  will  be  required  within  the 
Army  from  FY  98-03.  Figure  1  shows  a  framework  for  the  things  that  can  be  modeled  in  the 
synthetic  environment.  There  are  six  categories  shown:  time  frame,  applications  scope,  force 
type,  echelon,  phase  of  operation,  and  elements  to  be  modeled.  Each  category  addresses  a 
different  aspect  or  dimension  of  what  can  be  modeled  in  the  SE 
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4.1.1  Time  Frame 

At  a  macro  level,  what  can  be  modeled  in  the  synthetic  environment  are: 

•  The  current  systems 

•  The  emerging  systems 

•  The  visionary  systems. 

Modeling  current  systems  (vehicles,  units,  command  centers,  and  so  on)  and  their  capabilities  is 
an  on  going  activity  in  the  TEMO  domain.  If  it  already  exists  and  is  relevant  to  the  TEMO 
domain,  there  is  a  need  to  model  it  in  an  appropriate  level  of  detail.  Next,  there  is  the  need  to 
model  emerging  systems.  Modeling  future  systems,  systems  that  are  under  development  or  near 
deployment,  is  done  in  the  ACR  domain,  and  the  RDA  domain.  By  the  time  a  system  is 
deployed,  its  model  is  transitioned  to  the  TEMO  domain.  Models  of  visionary  systems  and 
experimental  capabilities  are  needed  to  support  the  work  of  people  in  the  ACR  and  RDA 
domains,  as  they  investigate  new  devices,  tactics,  techniques,  and  procedures  for  the  operational 
forces. 

4.1.2  Applications  Scope 

The  modeling  of  current,  future,  and  visionary  systems  will  be  done  to  investigate  options,  solve 
problems,  and  develop  new  approaches  for  the  following  categories  of  analytic  applications: 

•  Doctrine 

•  Training 

•  Leader  Development 

•  Organization 

•  Materiel 

•  Soldiers 

The  synthetic  environment  should,  therefore,  support  modeling  and  simulation  for  each  of  these 
applications. 

4.1.3  Force  Type 

The  synthetic  environment  should  support  a  broad  spectrum  of  Army,  joint,  and  coalition  forces, 
and  the  opposing  forces  for  all  of  these. 

4.1.4  Echelon 

There  is  a  need  for  the  SE  to  support  simulations  at  all  echelon  levels:  Theater,  Army,  Corps, 
Division,  Brigade,  Battalion,  Company,  Platoon,  and  the  individual  vehicle  and  soldier.  The 
intended  use  of  the  simulation  (e.g.,  educating  commanders  or  training  soldiers)  strongly  affects 
the  number  of  entities  that  need  to  be  represented,  their  degree  of  aggregation,  the  level  of  detail 
of  the  individual  entity  models,  and  the  field  of  view  and  visual  resolution  needed  from  the 
display  devices. 

4.1.5  Phases  of  Operation 

The  Army  has  defined  the  Force  Projection  Cycle,  which  categorizes  the  activities  of  units  from 
peacetime,  to  alert,  to  deployment,  through  operations,  and  back  to  peacetime  sustainment. 
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Simulation  of  each  phase  of  operation  defined  in  the  Force  Projection  Cycle  should  be  supported 
by  the  synthetic  environment: 

•  Alert 

•  Mobilization 

•  Deployment 

•  Early  Entry  Operations 

•  Operations 

•  Sustainment 

•  Recovery 

•  Redeployment 

•  Peacetime  Sustainment 

Ideally,  the  SE  would  provide  tools  so  that  the  simulation  moves  seamlessly  between  phases,  and 
the  effects  of  events  in  one  phase  properly  affect  downstream  phases. 

4.1.6  Elements  to  be  Modeled 

The  following  are  the  categories  of  elements  or  battlefield  entities  which  should  be  modeled: 

•  Vehicles 

•  Units 

•  Forces  (Collections  of  Units) 

•  Command,  Control,  Communication,  Computers  &  Intelligence  (C4I) 

•  Tactics  and  Behaviors 

•  Battlefield  Environment  (Synthetic  Natural  Environment) 

•  Specific  Locations  (Identification  of  the  Battlespace) 

The  term  Vehicles  includes  ground  and  air  vehicles  with  their  weapons  systems.  Units  consist  of 
collections  of  vehicles  and  soldiers.  Forces  consist  of  collections  of  units. 

The  C4I  structure  consists  of  the  communications  devices  and  networks,  the  voice  and  data 
traffic,  and  the  collection  and  distribution  of  intelligence  information.  Tactics  and  Behaviors 
address  how  commands  are  issued  and  executed  within  the  confinement  of  the  battlefield 
environment.  Included  within  the  Battlefield  Environment  category  are  the  elements  of  terrain, 
weather,  manmade  objects,  countermeasures,  and  weapons  effects.  Weapons  effects  include  fire, 
smoke,  and  damage  to  entities  on  the  battlefield.  Specific  Locations  consist  of  appropriate 
resolutions  of  Battlefield  Environment  information  at  actual  locations  throughout  the  world, 
including  test  and  training  ranges. 

4.2  Major  SE  Issues 

A  significant  part  of  this  effort  was  spent  identifying  the  SE  issues  which  most  need  to  be 
addressed.  The  results  are  summarized  in  Figure  2  in  an  approximate  priority  order.  Issues 
related  to  representing  the  synthetic  natural  environment  (SNE)  were  determined  to  be  the  most 
important.  These  were  followed  closely  by  representation  of  behaviors,  interoperability, 
reconfigurability,  and  C4I.  Finally,  there  were  numbers  of  entities  and  tools. 
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Figure  2.  Major  Synthetic  Environment  Issues 


4.2.1  Synthetic  Natural  Environment 

The  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  has  identified  the  SNE  issue  as 
important  for  the  synthetic  environment.  The  Close  Combat  Tactical  Trainer  (CCTT)  program 
worked  on  the  issue.  They  correctly  understood  that  the  sparseness  and  regularity  of  the 
SIMNET  database  had  a  significant  negative  impact  on  training.  Another  negative  impact  came 
from  the  lack  of  objects,  such  as  trees,  on  the  terrain.  The  CCTT  program  sought  to  develop  a 
much  more  realistic  synthetic  training  environment  that  would  provide  the  same  influence  on 
tactics  and  relative  effectiveness  as  in  the  real  world.  With  this  background  in  mind,  it  is 
necessary  to  define  what  constitutes  the  SNE,  how  SNE  representations  are  used,  and  to  describe 
some  of  the  SNE  issues  raised  in  the  interviews. 

4.2.1. 1  Definition  of  the  SNE 

The  definition  of  the  synthetic  environment  comes  from  the  DoD  and  Army  M&S  Master  Plans 
and  means  more  than  just  the  visual  scene  representation.  It  is  the  total  representation  of  the 
battlespace  created  to  support  a  training  exercise.  Within  the  synthetic  environment  there  are  two 
categories  of  objects:  the  warfighting  entities  present  in  the  battlespace  and  the  natural 
environment  with  its  cultural  and  natural  features.  The  natural  environment  covers  all 
environmental  domains:  terrain,  ocean,  atmosphere,  and  space.  When  simulating  these  features, 
it  is  important  that  their  geographic  location  is  as  accurate  as  possible. 

4.2.1. 2  How  the  SNE  Representations  Are  Used 

The  representations  of  the  synthetic  natural  environment  include  the  data  and  attributes 
describing  all  of  the  objects  and  features  in  the  battlespace.  They  also  include  data  that  is  used  to 
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improve  computational  performance  related  to  the  level  of  detail  in  the  simulation.  Data  types 
now  in  the  synthetic  natural  environment  databases  can  be  used  to  improve  the  fidelity  of  the 
simulation.  When  new  data  types  are  added,  they  must  be  correlated  with  the  existing  data  types, 
so  that  the  result  is  an  integrated,  single,  coherent  representation  in  the  simulation.  This  is 
particularly  important  when  two  or  more  simulations  federate  for  a  simulation. 

To  help  put  the  remainder  of  this  discussion  in  perspective,  it  is  necessary  to  examine  the  SNE 
generation  process.  Figure  3,  SNE  Interactions,  shows  one  way  to  represent  what  is  happening 
between  the  computer  models  that  comprise  the  SNE.  These  models  are  mathematical 
representations  of  entities,  objects,  or  situations.  The  models  are  combined  with  each  other  and 
with  an  infrastructure  to  create  a  simulation.  Software  models  usually  cannot  execute  by 
themselves.  They  need  inputs  and  data  from  other  models.  The  entities  represented  by  these 
models  are  also  referred  to  as  Mission  Space  Objects  (MSO). 


SNE  Representation 


Com  ponent 
M  odels 


Behavior 
M  odels 


Figure  3.  SNE  Interactions 

A  version  of  the  conceptual  model  above  was  proposed  and  can  be  found  in  the  draft  Joint 
Simulation  System  (JSIMS)  Technical  Notice  #9.  The  original  version  has  been  modified  here  to 
explicitly  show  the  feedback  mechanisms.  This  figure  indicates  how  the  component  and  behavior 
models  interact  with  the  SNE  representations.  It  is  evident  that  there  is  input  directly  from  the 
SNE  representation  into  the  behavior  models  and  feedback  from  the  behavior  models  to  the  SNE 
representation.  The  interactions  between  the  various  models  is  facilitated  by  a  common  data 
exchange  format.  Previously,  proprietary  databases  were  developed  and  the  reuse  of  these  data 
was  limited.  To  alleviate  this  interoperability  problem,  a  program  named  Synthetic  Environment 
Data  Representation  and  Interchange  Specification  (SEDRIS)  was  established.  SEDRIS  is  not  a 
database,  but  is  an  interchange  format  between  databases  and/or  models.  Using  the  SEDRIS 
format  will  allow  multiple  users  to  access  and  exploit  SE  representations  developed  for  other 
simulation  systems. 
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The  Mission  Space  Objects  are  the  actual  entities  in  the  real  world  being  modeled  during  runtime 
to  create  the  synthetic  battlespace.  A  non-exhaustive  list  of  MSOs  includes  sensors,  aggregates, 
command  and  control  decision-makers,  and  the  environments,  such  as  the  weather  and  terrain. 
Figure  4  is  a  flow  chart  of  the  MSO  process.  The  classifying  of  the  MSO  occurs  in  steps  1-3. 
Step  1  examines  its  physical  presence.  Is  it  physically  measurable?  Does  it  have  one  or  more 
physical  locations  associated  with  it?  The  second  step  asks  if  the  entity  is  a  military,  civilian,  or 
biological  system.  A  subset  of  this  is  to  determine  if  it  is  a  manmade  object  and  if  it  can  move. 
The  biological  portion  is  concerned  with  all  living  things  except  plants.  If  the  entity  is  neither 
type  1  nor  2,  then  the  third  question  is  whether  the  entity  is  a  military  or  civilian  control  measure. 
An  example  of  a  military  control  measure  is  controlling  the  airspace  or  the  forward  edge  of  the 
battle  area.  Examples  of  civilian  control  measure  are  administrative  boundaries,  shipping  lanes, 
and  civilian  air  routes.  The  SNE  MSO  has  now  been  identified  and  classified.  There  are  two 
remaining  steps  which  include  determining  whether  the  MSO  is  man-made  or  if  it  occurs 
naturally.  A  man-made  MSO  is  like  an  acoustic  noise  or  RF  emission,  whereas,  a  naturally 
occurring  MSO  is  like  leaves  falling  or  wind  creating  dust.  This  whole  procedure  is  more  fully 
discussed  in  JSIMS  Technical  Notice  #10. 
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Figure  4.  MSO  Determination  and  Classification 
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4.2.1.3  SNE  Issues  Raised  in  the  Interviews 

Many  of  the  interviews  were  very  specific  about  how  the  process  of  SNE  model  development 
should  take  place.  In  a  phrase,  the  models  need  a  higher  degree  of  fidelity.  Real  physical  models 
should  be  integrated  into  the  simulations  and  higher  resolution  simulators  should  be  developed. 
At  the  same  time,  the  developments  should  be  portable  from  one  simulation  to  another.  The 
proprietary  solution  should  be  avoided. 

Common  formats  should  be  developed  and  fielded.  This  includes  the  SEDRIS  work  mentioned 
above  to  enable  the  interoperability  of  databases  and  data  sets.  Within  the  realm  of 
interoperability  for  the  SNE,  all  models  should  be  made  HLA  compliant.  This  may  require  some 
models  to  be  re-engineered  to  meet  near  real  time  needs. 

If  one  phrase  could  sum  up  the  general  consensus  of  the  SNE  interviewees,  it  is  that  more 
physics  based  models  need  to  be  incorporated  into  the  simulations  and  a  common  interchange 
format  is  needed  to  ensure  interoperability. 

4.2.2  Representation  of  Behaviors 

The  representation  of  behaviors  follows  closely  behind  the  SNE  as  a  major  issue  and  concern 
with  the  individuals  interviewed.  This  correlates  well  with  the  M&S  Master  Plan  and  its  six 
objectives.  One  of  those  objectives  spoke  to  providing  authoritative  representation  of  behaviors. 
Areas  of  interest  mentioned  in  the  interviews  included  representing  individuals,  vehicles  with 
crews,  units,  and  staffs.  This  concept  is  evident  in  Figure  2  SNE  Interactions.  In  this  figure  there 
are  interactions  between  the  SNE  and  the  behaviors,  between  the  component  models  (sensors, 
weapons,  etc.)  and  the  behaviors,  and  the  behaviors  in  turn  affect  the  SNE  (via  vehicle  tracks, 
smoke  deployed,  weapons  fired,  etc.) 

4.2.2.1  Important  Behaviors 

The  final  step  in  Figure  3  MSO  Determination  and  Classification  provides  input  into  the 
behavior  models.  There  are  two  basic  types  of  behaviors.  The  first  is  man-made.  The  developer 
must  define  the  behavior  associated  with  the  physical  functionality  of  an  object,  i.e.  how  it 
affects  sensory  systems  or  movement.  If  an  object  is  a  naturally  occurring  one,  the  developer  has 
to  model  this  second  type,  called  natural  behavior.  There  are  two  basic  categories  within  the 
naturally  occurring  behaviors:  internal  dynamics  and  interactions.  With  internal  dynamics, 
behavior  is  affected  over  time.  An  example  of  this  is  the  change  of  seasons.  Interactions  can 
occur  between  MSOs.  The  developer  must  develop  a  mechanism  to  provide  an  assessment  of  the 
result  of  the  interaction.  An  example  of  this  is  when  a  munition  strikes  the  ground  instead  of  its 
target.  The  physical  state  of  the  terrain  changes  and  needs  to  be  modeled. 

Now  refer  back  to  Figure  2  SNE  Interactions.  The  SNE  Working  Group  had  proposed  the 
original  figure  to  illustrate  the  important  relationships  between  the  environment,  the  component 
models,  and  the  behavior  models.  It  was  also  intended  to  show  the  ultimate  effect  that  the 
environment  has  on  the  behaviors.  There  are  several  important  behaviors  that  the  environment 
can  affect.  They  range  from  scouting,  marching,  and  occupying  to  fire,  search  and  find,  and 
tracking.  Such  behavior  models  need  to  be  developed  for  individuals,  vehicles  with  crews,  units, 
staffs,  and  any  other  human  controlled  entity  that  is  proposed  to  be  modeled  in  the  SE. 
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4.2.2.2  Behavior  Issues  Raised  in  the  Interviews 

From  the  many  interviews,  there  is  the  desire  to  easily  modify  the  represented  behaviors.  This 
modification  can  occur  for  two  reasons.  The  first  is  that  the  individual,  vehicle,  unit,  or  staff 
behavior  may  need  to  be  modified,  because  a  weapon  affected  them.  The  second  reason  may  be 
that  they  were  affected  by  an  outside  source.  This  outside  source  would  include  modification  by 
the  game  director  to  achieve  a  desired  learning  objective. 

A  number  of  the  interviewees  were  adamant  about  the  need  for  increasing  the  fidelity  of  the 
physical  models.  They  also  spoke  of  the  need  to  make  the  environment  more  credible  and  to 
couple  sensors  with  the  environment  and  the  environment  with  the  troops.  That  also  applies  to 
the  behaviors.  The  simulation  needs  the  ability  to  react  to  the  changing  conditions,  including 
changing  environmental  conditions.  The  interviewees  distinguished  between  two  types  of 
changing  conditions.  The  first  conditions  are  environmental.  This  includes  weather  effects  such 
as  rain,  clouds,  temperature,  and  so  on.  These  conditions  can  impact  behaviors.  The  second 
changing  conditions  are  the  impact  of  actions  by  individuals,  vehicles,  and  units.  When  the 
environment  changes  as  a  result  of  such  actions,  it  should  be  reflected  in  the  simulation  to  ensure 
the  proper  degree  of  realism.  Component  models  can  also  change  the  environment  because  a 
weapon  can  impact  an  individual,  vehicle,  or  unit  thus  changing  the  simulation  and  the  behavior. 

As  has  been  briefly  outlined  above,  there  are  many  impacts  of  the  behaviors  that  are  not 
represented  realistically.  This  loss  of  realism  can  lead  to  simulations  that  may  not  meet  the 
analysis  or  training  objectives.  One  outcome  could  be  a  deficiency  in  the  knowledge  acquired  by 
individuals  being  trained.  This  is  one  reason  that  many  of  the  interviewees  expressed  the  need  for 
more  accurate  representation  of  the  behaviors.  Another  reason  is  so  that  SAFs  and  CGFs  can 
better  represent  the  behaviors  of  commanders,  staffs,  and  units  at  higher  echelons. 

4.2.3  Interoperability 

This  area  was  a  major  issue  identified  by  those  interviewed.  Comments  ranged  from  the  need  to 
integrate  diverse  simulators  not  designed  to  operate  together,  to  designing  future  simulators  for 
interoperability.  The  problems  of  interoperability  can  be  of  a  hardware  or  software  nature.  They 
manifest,  for  example,  when  corresponding  hardware  components  cannot  be  connected  together 
or  the  databases  used  by  one  simulation  are  incompatible  with  that  of  another  simulation. 
Addressing  this  in  the  past  led  to  many  one-of-a-kind  software  or  hardware  solutions  that  are 
often  costly,  proprietary,  or  both. 

Also  mentioned  in  the  interviews  were  the  difficulties  in  having  a  “fair  fight”  between  two 
simulators.  This  can  happen,  for  instance,  if  simulator  A  has  more  robust  algorithms  for 
depicting  shadows,  terrain,  and  other  common  obscurants,  than  simulator  B.  It  can  also  happen 
due  to  differences  in  representing  the  terrain  database.  Vehicle  A  could  be  behind  a  hill  in 
relation  to  Vehicle  B,  but  Vehicle  B  could  be  in  plain  view  to  Vehicle  A  in  its  simulation. 

4.2.4  Reconfigurability 

A  point  that  was  raised  in  several  of  the  interviews  was  the  need  to  design  simulations  or 
simulators  with  combined  capabilities.  Instead  of  having  individual  simulators  for  each  type  of 
training  (e.g.,  a  tank  gunnery  trainer  and  a  separate  tank  driver  trainer),  have  a  reconfigurable 
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simulator  that  can  replicate  many  different  types  of  training  (gunnery  and  driver  training  for 
tanks,  armored  personnel  carriers,  self-propelled  artillery,  etc.) 

Another  aspect  of  reconfigurability  is  reprogramming  specific  vehicle  capabilities  for  different 
experiments,  exercises,  or  training  missions.  This  includes  reconfiguring  the  software  to  create 
different  types  of  C4I  displays. 

4.2.5  Command,  Control,  Communication,  Computers,  and  Intelligence  (C4I) 

There  were  two  categories  of  issues  identified  relative  to  C4I.  They  were: 

•  Representation  of  communication  networks, +  bandwidth,  and  loading,  and 

•  Integration  of  C4I  systems  with  the  SE. 

4.2.5.1  Representation  of  Communication  Networks 

Communications  network  simulation  is  lacking  in  many  models  and  simulations.  It  is  common  to 
model  perfect  communications  and  unrealistically  wide  bandwidths.  When  this  is  done,  the 
delays,  bandwidth  limitations,  and  line  of  sight  restrictions  of  real  world  communications  are  not 
present  in  the  simulation.  One  result  is  that  the  participants  in  a  test  or  exercise  can  achieve 
overly  optimistic  results  and  are  being  trained  to  expect  much  better  communications  than  are 
achievable  in  a  real  operation.  They  are,  therefore,  not  learning  how  to  work  within  and 
compensate  for  the  limitations  of  real  world  communications  systems. 

The  Army's  communication  system  architecture  is  changing  from  the  present  packet  switched 
architecture  to  the  Warfighter  Information  Network,  which  is  looking  at  Asynchronous  Transfer 
Mode  (ATM)  switching.  This  will  affect  the  modeling  of  future  communications. 

4.2. 5.2  Integration  of  C4I  Systems  into  the  SE 

Current  C4I  systems  were  not  designed  to  facilitate  interfacing  into  the  SE.  Many  were  not  even 
designed  to  facilitate  interoperating  with  other  dissimilar  C4I  systems.  The  Joint  Technical 
Architecture  is  an  on-going  effort  to  define  C4I  interface,  protocol,  message  format,  and  data 
format  standards  to  help  alleviate  this  problem  for  future  C4I  systems. 

For  current  systems,  it  is  necessary  to  engineer  specific  interfaces  between  each  type  of  C4I 
system  and  the  SE.  Most  of  the  recent  interfaces  have  been  software  translators,  like  Modular 
Reconfigurable  C4I  Interface  (MRCI)  and  Tactical  Simulation  Interface  Unit  (TSIU).  There  is  a 
need  for  a  more  generalized  solution.  There  is  also  a  need  for  a  cooperative  effort  by  C4I 
developers  and  SE  developers  to  work  toward  facilitating  particular  solutions  while  trying  to 
develop  more  generalized  solutions  for  interfacing  between  C4I  and  the  SE.  Adhering  to  JTA 
would  simplify,  but  would  not  guarantee,  this  interoperability. 

4.2.6  Number  of  Entities 

The  battle  laboratories  expressed  the  need  to  be  able  to  conduct  larger  fights  to  support  their 
missions  to  develop  new  tactics,  techniques,  and  procedures  against  potential  adversaries.  As 
computer  power  (processor  speed,  memory,  and  storage)  and  network  bandwidth  increase,  it  is 
possible  to  simulate  larger  and  larger  numbers  of  entities.  This  issue  is  also  closely  related  to  the 
issue  of  representation  of  behaviors  (Section  3.2.2).  A  companion  aspect  of  the  number  of 
individuals,  units,  vehicles,  and  staffs  that  are  represented  in  the  simulation  is  the  level  of  detail 
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of  representing  each  entity.  This  must  be  balanced  with  the  computational  power  available  in  the 
simulation.  Another  aspect  is  the  resolution  of  the  visual  image  of  an  entity.  The  closer  the  entity 
is  to  a  live  participant  in  the  SE,  the  higher  the  resolution  that  is  needed.  Conversely,  the  farther 
an  entity  is  from  the  main  focal  point  of  the  simulation,  the  lower  the  resolution  of  the  entity  can 
be.  Taking  advantage  of  this  fact  could  allow  for  creating  more  diverse  units,  which  allows  for 
higher  fidelity  simulations  within  the  same  computer  and  display  generator  capabilities. 

4.2.7  Tools 

A  tool  can  be  any  combination  of  hardware  or  software  that  helps  achieve  the  objective  of  the 
simulation.  Tools  can  be  used  to  design  simulations,  develop  simulations,  set-up  simulations, 
collect  data  on  simulations,  and  analyze  data  from  simulations.  These  are  the  most  common  uses 
for  tools  in  the  SE.  Another  class  of  tools  help  the  Program  Managers  plan  and  manage 
programs.  There  are  a  number  of  commercial  off  the  shelf  (COTS)  tools  which  are  available  to 
aid  in  planning  and  managing  programs. 

Most  of  the  interviewees  who  mentioned  tools  were  interested  in  tools  to  support  tests,  exercises, 
and  experiments.  There  is  a  strong  need  for  tools  that  can  facilitate  the  setup,  execution, 
monitoring,  and  evaluation  of  the  simulation.  When  the  simulation  is  completed,  there  is  a  need 
for  standard,  easy  to  use  tools  to  better  evaluate  the  success  of  the  simulation. 

4.3  Enabling  Technologies 

As  shown  in  Table  3,  there  are  eight  major  categories  of  enabling  technologies  that  support  the 
development  of  solutions  to  the  issues  discussed  in  Section  3.2.  Advances  in  some  of  these 
categories  are  driven  entirely  by  needs  in  the  commercial  arena,  e.g.,  non-militarized  computers, 
display  devices,  display  generators,  networks,  computer  operating  systems,  and  software 
development  and  analysis  tools.  The  Army,  as  a  customer,  is  so  small  relative  to  the  commercial 
market  that  it  cannot  expect  to  impact  any  of  these  developments.  However,  the  Army  must 
remain  alert  to  what  is  happening  in  the  commercial  sector,  and  make  optimal  use  of  appropriate 
commercial  off  the  shelf  (COTS)  products  as  they  become  available.  The  remainder  of  the 
enabling  technologies  will  require  investments  by  the  Army  to  develop  the  needed  items.  This 
Army  investment  is  required,  because  there  is  no  viable  commercial  market  for  these  products, 
i.e.,  SE  architecture,  custom  man  machine  interfaces,  many  military  specific  software 
applications,  and  most  of  the  tools. 
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ENABLING  TECHNOLOGIES 


Architectures 

Computers 

Display  Devices 

Display  Generators 

Man  Machine  Interfaces 

Networks 

Software 

•  Operating  Systems 

•  Application  Program  Interfaces 

•  Applications  and  Models 

•  Graphical  User  Interfaces 

•  Databases 
Tools 


Table  3.  Enabling  Technologies 


4.3.1  Architectures 

There  are  several  levels  of  architecture  to  address.  At  the  highest  level  is  the  architecture  of  the 
overall  synthetic  environment.  The  SE  architecture  defines  the  functional  partitioning,  as  shown 
in  Figure  1,  Top  Level  Block  Diagram  of  the  Synthetic  Environment.  It  defines  the  interfaces, 
the  information  that  passes  between  the  partitions,  and  how  that  information  is  passed.  The  major 
distributed  simulation  architectures  to  date  have  been  the  Simulation  Network  (SIMNET),  the 
Distributed  Interactive  Simulation  (DIS),  the  Aggregate  Level  Simulation  Protocol  (ALSP),  and 
the  High  Level  Architecture  (HLA).  There  is  some  preliminary  thought  being  given  to  what  the 
architecture  after  HLA  might  be.  Some  are  postulating  that  it  will  be  a  composable  architecture 
that  would  enable  a  user  to  rapidly  define,  set  up,  execute,  and  analyze  a  SAF  or  CGF  scenario. 
Setup  would  be  done  by  building  vehicles,  units,  and  behaviors  by  selecting  and  combining 
objects  from  libraries  of  reusable  models.  Execution  and  analysis  would  also  use  library  tools. 

The  next  level  of  architecture  is  within  each  of  the  functional  blocks  in  Figure  1 :  the  C4I,  the 
manned  simulators,  the  SAFs,  and  the  CGFs.  The  architecture  within  each  block  determines  how 
easy  or  difficult  it  is  to: 

•  Initially  embed  functional  capabilities  within  those  blocks. 

•  Modify  and  enhance  the  functionality  of  the  model  as  needs  change  in  the  future. 

•  Reuse  the  model  or  transition  the  model  to  a  different  SE  architecture,  such  as  from 
DIS  to  HLA,  from  standalone  to  HLA,  or  from  HLA  to  the  next  SE  architecture. 

The  third  level  of  architecture  is  that  of  the  software  running  within  each  computer  that  is  used  to 
implement,  for  example,  a  manned  simulator  or  a  SAF.  As  with  the  second  architecture  level, 
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this  strongly  affects  how  easy  or  difficult  it  is  to  modify  and  enhance  the  functionality  of  the 
model  as  needs  change  in  the  future. 

4.3.2  Computers 

Driven  by  demand  in  the  commercial  market,  there  has  been  a  tremendous  increase  over  the  past 
fifteen  years  in  all  facets  of  computer  technology,  from  the  clock  speed  and  computational  power 
to  available  RAM,  to  on-line  data  storage.  Microprocessor  computational  power  has  doubled 
approximately  every  1 8  months.  The  cost  of  RAM  has  decreased  at  the  same  rate.  Each  time  it 
has  appeared  that  there  might  be  a  technological  barrier  or  limit,  a  solution  has  been  found  and 
the  barrier  has  been  hurdled.  No  one  sees  any  insurmountable  barriers  to  the  continuation  of 
these  trends. 

The  latest  Pentium  and  Merced  microprocessors  have  enormous  computer  power  and  huge 
commercial  markets.  Their  present  computational  power  exceeds  that  of  the  Sun  and  Silicon 
Graphics  (SGI)  workstations  of  just  a  few  years  ago,  and  at  a  much  lower  cost.  The  Army’s 
M&S  activities  are  minuscule  compared  to  the  commercial  market  and  it  will  be  able  neither  to 
specify,  nor  to  develop,  its  own  computers.  The  Army’s  M&S  role  is  as  a  user  of  commercially 
available  computers.  There  are  likely  significant  cost  and  system  development  time  advantages 
that  the  Army  can  gain  by  being  a  pro-active  follower  of  computer  technology  trends  and 
transitioning  away  from  higher  cost,  more  difficult  to  use  UNIX  workstations,  to  lower  cost, 
easier  to  use  Windows  NT  personal  computers  for  implementing  elements  of  the  synthetic 
environment. 

4.3.3  Display  Devices 

Display  devices  include  computer  monitors,  cathode  ray  tubes  (CRT)  of  various  sizes,  large 
screen  rear  and  front  projection  displays,  liquid  crystal  display  (LCD)  and  active  matrix  color  flat 
panel  displays,  and  helmet  mounted  displays.  Each  has  its  role  in  displaying  information  to 
participants  in  or  users  of  the  synthetic  environment.  The  technology  for  all  of  these,  with  the 
exception  of  some  of  the  militarized  helmet  mounted  displays,  is  driven  entirely  by  demand  in 
the  commercial  marketplace.  The  Army’s  M&S  programs  are  too  small  to  affect  any  of  these 
developments  and  again  have  a  role  only  as  a  user  of  commercially  available  display  devices.  It 
should  take  a  pro-active  role  in  staying  current  with  the  available  commercial  display  devices 
and  those  under  development,  so  they  can  be  utilized  as  needed  in  implementing  the  SE. 

4.3.4  Display  Generators 

It  was  not  too  long  ago  that  the  market  for  computer  image  generators  (CIG)  was  dedicated 
almost  entirely  to  military  M&S  programs.  CIGs  were  very  large  and  very  expensive,  semi¬ 
custom  devices  used  for  military  applications,  such  as  generating  out-the-window  views  in 
aircraft  cockpit  simulators.  Many  of  those  CIGs  are  still  being  used  in  their  original  systems. 
However,  the  market  for  image  generators  or  display  generators  has  been  driven  for  some  years 
by  the  commercial  market  for  computer  games.  For  example,  the  former  GE  Daytona,  at  one 
time  a  leader  in  CIGs  for  aircraft  simulators,  has  now  become  a  commercial  spin-off  from  the 
Lockheed  Martin  Company.  Their  two  most  important  products  are:  1 .  A  display  generator  chip 
set  and  circuit  board  used  in  video  arcade  games  and  2.  A  new  display  generator  chip  developed 
for  Intel  Corporation.  By  recognizing  and  taking  advantage  of  the  commercial  development 
trends,  the  Army  can  have  the  latest  technology  display  generators  in  its  implementation  of 
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synthetic  environments.  This  will  provide  ever  increasing  computer  graphics  capability,  at  low 
acquisition  costs. 

The  major  precaution  in  using  commercial  products  is  that  they  become  obsolete  very  quickly- 
from  six  to  eighteen  months  in  many  cases.  To  utilize  cost  effective  commercial  products,  the 
implementation  must  be  highly  modular,  so  that  the  commercial  devices  can  be  easily  replaced 
with  the  latest  model.  Care  must  be  take  to  ensure  that  each  implementation  is  not  unduly 
dependent  on  the  peculiarities  of  a  particular  device,  which  can  soon  become  obsolete  and 
unavailable. 

4.3.5  Man  Machine  Interface 

A  Man  Machine  Interface  exists  to  enable  the  user  to  better  interact  with  the  computer  simulation 
operating  at  the  time.  This  is  important,  because,  as  simulations  become  more  complex  or  have 
more  variables  to  consider,  the  user  must  be  able  to  input,  change  or  refine  those  inputs.  Also,  a 
man  machine  interface  enables  the  user  to  receive  input  from  the  simulation.  However,  care  must 
be  taken  to  ensure  the  training  required  to  use  the  interface  is  minimal. 

The  interface  design  should  consider  three  factors.  First,  it  should  allow  for  easy  interaction  with 
the  simulation.  This  can  be  accomplished  by  using  open  architecture  and  common  operating 
systems.  Ideally,  the  computer  simulation  should  not  require  any  special  training  for  its  use.  This 
will  enable  the  user  to  get  the  maximum  benefit  from  the  simulation.  Second,  the  interface 
should  be  matched  to  the  type  of  simulation  and  the  requirements.  For  example,  some 
simulations  require  only  voice  input.  Therefore,  only  voice  commands  are  needed,  not  graphical 
inputs.  Also,  all  interactions  with  the  simulation  should  be  through  organized  systems.  This  will 
inherently  allow  for  interfacing  with  command  and  control  systems.  The  third  factor  is  the 
commercial  market.  It  is  believed  that  the  commercial  sector  will  drive  the  types  of  interface 
technology  developed.  Users  in  the  future  will  be  familiar  with  Sega  type  games.  If  the  interface 
is  designed  with  that  in  mind,  the  technology  will  be  developed  by  industry  for  video  games. 

This  will  free  simulation  dollars  to  be  spent  on  developing  data  format  structures  and  other 
algorithms  required  for  the  military  application. 

As  mentioned  above,  there  are  types  of  interfaces  that  only  require  a  voice  interface  for 
personnel  directly  interacting  with  the  simulation.  The  simulation  should  be  able  to  recognize  a 
multitude  of  voice  commands  and  respond  to  those  commands.  Once  again  the  commercial 
sector  has  developed  this  technology  and  it  only  needs  to  be  applied.  Software,  such  as  Verbex, 
has  a  vocabulary  of  several  hundred  words  or  phrases. 

By  recognizing  these  latest  technologies,  the  Army  can  take  advantage  of  the  latest 
developments.  This  will  provide  a  continued  increase  in  capability,  if  the  simulation  is 
engineered  to  allow  for  the  easy  replacement  of  the  software  or  hardware  it  uses. 

4.3.6  Networks 

As  with  computers  and  display  devices,  this  area  is  driven  by  the  commercial  market.  The  Army 
should  take  advantage  of  the  developments  that  will  occur.  Being  pro-active  will  ensure  that  the 
network  technology  used  by  the  Army  remains  current  and  supportable. 
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4.3.7  Software 

The  software  can  be  conveniently  subdivided  into  five  areas  for  discussion  purposes:  operating 
systems,  application  program  interfaces  (API),  applications  and  models,  graphical  user 
interfaces,  and  databases.  Of  these,  the  operating  systems,  most  software  development, and 
software  analysis  tools  will  be  COTS  products.  The  rest  of  the  software  will  be  custom, 
semicustom,  reused,  or  modifications  of  software  that  already  has  been  developed  to  meet  the 
specific  needs  of  the  SE. 

4.3. 7.1  Operating  Systems 

There  are  two  operating  systems  of  major  interest  to  the  synthetic  environment:  UNIX  and 
Windows  NT.  A  version  of  UNIX  is  the  operating  system  for  most  computers  currently  being 
used  in  the  SE.  This  is  not  necessarily  due  to  the  superior  quality  of  this  operating  system,  but 
rather  because  this  operating  system  was  provided  with  the  Sun  and  SGI  classes  of  workstations. 
Workstation  class  computers  have  been  used  in  most  SE  applications,  because  of  the  amount 
computer  horsepower  they  have.  As  was  mentioned  in  Section  3.3.2,  the  latest  Pentium  and 
Merced  microprocessors  have  greater  computer  horsepower  than  the  Sims  and  SGIs  of  just  a  few 
years  ago,  and  they  cost  much  less.  For  these  Intel  microprocessors,  Windows  NT  is  a  superior 
operating  system  to  UNIX.  To  take  advantage  of  the  advances  in  the  commercial  arena,  the  trend 
should  be  to  Pentium  and  Merced  microprocessors  as  the  basis  for  the  computer  hardware,  and  to 
Windows  NT  as  the  operating  system. 

4.3. 7.2  Application  Program  Interfaces 

The  application  program  interface  is  what  its  name  implies.  It  is  a  layer  of  software  which  serves 
as  an  easy  to  use  interface  between  the  operating  system  and  the  application  program.  It  is 
usually  language  specific,  e.g.,  a  set  of  C++  functions  which  the  C++  application  program  calls, 
when  operating  system  functions  are  needed  by  the  application  program.  There  should  be  a  high 
degree  of  reuse  of  well  designed  APIs. 

4.3.7. 3  Applications  and  Models 

The  application  software  and  the  models  will  be  implemented  with  custom  software.  The  Army 
will  have  to  write,  or  pay  contractors  to  write,  all  of  this  software.  The  potential  for  cost 
avoidance  occurs  when  the  applications  and  models  are  modular,  well  designed,  and  well 
documented.  When  they  are  then  finding  and  fixing  bugs  is  much  simpler.  Also,  software 
models  can  be  more  easily  maintained  and  upgraded  when  the  underlying  entity  (e.g.,  Ml  A2 
Abrams)  is  upgraded.  And  finally,  reuse  or  reuse  with  modification  is  easier  across  the  three 
domains,  and  across  multiple  programs. 

4.3. 7.4  Graphical  User  Interface 

The  tools  for  designing,  prototyping,  and  building  graphical  user  interfaces  (GUI)  are  COTS 
products.  The  GUIs  themselves  are  custom  designs.  The  intuitiveness  of  the  GUI  facilitates 
learning  new  applications  easily.  It  is  the  power  behind  the  GUI  that  makes  it  fast  and  efficient 
for  performing  the  operations  needed  to  define,  set  up,  and  operate  the  SE  and  for  selecting  and 
analyzing  data. 

The  Army’s  functions  relative  to  GUIs  are  primarily  as  specifiers,  design  overseers,  and  end 
users.  They  should  be  intimately  involved  in: 
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•  Preparing  the  specifications  for  GUIs  that  will  be  used  by  Army  personnel  and  Army 
contractors. 

•  Assuring  that  the  Army’s  usability  objectives  are  being  met  through  participation  in  the 
detailed  design  reviews  of  GUIs. 

•  Assuring  that  the  designs  and  documentation  are  complete  and  robust  through  careful 
specification  and  review  of  user  documentation,  including  on-line  help  documentation. 

•  Assuring  that  the  documentation  is  easy  to  understand  and  facilitates  learning  to  use  the 
system  effectively  and  efficiently. 

4.3. 7.5  Databases 

There  are  four  key  aspects  of  databases.  First  is  the  structure  of  the  database.  The  structure 
determines  what  kinds  of  data  can  be  stored,  how  that  data  is  stored,  how  much  data  can  be 
stored  on  a  particular  device,  and  what  processes  can  be  used  for  storing  and  retrieving  data. 
Second  is  the  process  or  processes  used  to  prepare  the  data  and  store  it  in  the  database.  Third  is 
the  process  of  retrieving  data  from  the  database.  Fourth  is  the  actual  content  of  the  database:  the 
data  that  is  prepared,  stored,  and  later  retrieved.  Databases  are  powerful  and  flexible  concepts 
and,  when  well  thought  out  and  properly  implemented,  can  greatly  simplify  the  building  and 
modifying  of  models  and  simulations.  The  deliberate  definition  and  use  of  common  databases 
can  facilitate  the  reuse  and  integration  of  models  across  multiple  applications  within  the  three 
M&S  domains.  As  part  of  the  process  of  developing  databases,  it  is  equally  important  to  develop 
software  which  can  accept  the  raw  data  in  its  various  formats  and  quickly  prepare  it  and  load  it  in 
the  appropriate  databases.  Provisions  must  also  be  made  for  verifying  the  database  contents  and 
for  assuring  its  integrity. 

4.3.8  Tools 

The  purpose  of  a  tool  is  to  help  perform  an  activity  easier,  faster,  cheaper,  and/or  better. 

Effective  tools  can  save  large  amounts  of  effort  and  can  significantly  reduce  costs.  There  are 
many  tools  which  have  been  and  are  being  used  to  design,  develop,  set  up,  operate,  and  maintain 
various  aspects  of  the  SE.  There  are  general-purpose  COTS  tools,  such  as  editors,  language 
compilers,  linkers,  loaders,  and  symbolic  debuggers.  There  are  COTS  tools  to  support  building 
and  maintaining  libraries  and  for  configuration  management.  As  mentioned  previously,  there  are 
COTS  tools  for  building  GUIs.  For  the  most  part,  the  other  tools  that  will  be  needed  will  be 
custom  tools  developed  with  Army  funds,  or  reused  from  tools  developed  by  the  other  services. 
This  means  that  the  Army  should  try  to  assure  that  their  programs  develop  good  tools  and 
document  them  well.  Whenever  possible,  the  tools  should  try  to  have  broader  application  than 
just  the  program  at  hand.  It  also  means  that  there  should  be  a  focal  point  within  each  service  with 
knowledge  of  a  repository  of  available  tools  and  documentation,  to  facilitate  reuse  and  minimize 
duplication  of  effort. 
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5.  SUMMARY  OF  EXECUTION  PLANS 

5.1  STRICOM  Business  Environment 

In  this  section  we  summarize  the  execution  plans  that  address  both  the  enabling  technologies  and 
the  synthetic  environment  issues  that  were  identified  during  the  interviews.  The  SE  issues  were 
discussed  in  Section  4.2.  The  enabling  technologies  were  discussed  in  Section  4.3. 

Since  viable  execution  plans  must  be  compatible  with  the  business  environment  in  which 
STRICOM  operates,  we  begin  by  examining  that  business  environment.  There  is  a  colloquial 
motto  which  states,  “The  Golden  Rule:  He  who  has  the  gold  makes  the  rules.”  Although  cynical, 
this  motto  captures  the  essence  of  business  operations.  This  relates  to  the  synthetic  environment, 
because  there  is  a  mismatch  between  the  way  programs  are  funded  and  controlled  and  the  overall 
needs  of  the  SE. 

There  is  much  that  can  be  done  to  improve  the  synthetic  environment  that  would  benefit  both 
those  who  pay  for  developing  the  SE  and  the  end  users  of  the  SE  capabilities.  These  benefits 
include  easier  setup  and  control  of  experiments  and  tests,  better  interoperability  and 
reconfigurability,  better  data  collection,  and  better  analysis  tools.  They  could  also  include  lower 
combined  development,  operation,  and  maintenance  (life  cycle)  costs.  Achieving  these 
improvements  could  be  facilitated  by  doing  a  better  job  of  defining  requirements,  developing 
architectures  and  interfaces,  developing  and  conforming  to  M&S  standards,  designing  for  ease  of 
use,  and  designing  with  modularity  and  reuse  as  objectives.  These  things  are  achievable  over 
time,  through  appropriate  coordination,  cooperation,  and  shared  visions  within  the  Army  and 
across  the  Services  and  programs.  However,  money  is  a  key  driving  function  in  this  process. 
There  needs  to  be  a  willingness  and  incentive  on  the  part  of  those  with  the  funds  to  invest  in 
these  objectives  and  visions. 

In  project  driven  environments,  such  as  STRICOM's,  most  of  the  funds  are  provided  to  and 
controlled  by  the  program  managers.  With  few  exceptions,  program  managers  are  tightly  focused 
on  their  individual  programs.  Therefore,  in  such  an  environment,  it  is  necessary  for  STRICOM  to 
exercise  the  vision  needed  to  coordinate  investment  from  existing  programs  toward  the  future, 
the  core  infrastructure  capabilities,  and  an  improved  SE.  Recognizing  that  benefits  were  gained 
from  earlier  programs,  STRICOM  needs  to  continue  to  make  investments  that  will  benefit  both 
current  programs  and  others  in  the  future  and  to  create  incentives  for  program  managers  to 
contribute  to  such  efforts.  Such  coordinated  investments  are  needed,  because  the  development 
costs  are  beyond  the  scope  of  any  one  program. 

By  teaming  with  other  programs,  investment  resources  (personnel  and  funds)  will  be  maximized, 
thus  creating  a  more  robust  synthetic  environment.  This  requires  cooperation  across  three 
perspectives  of  the  SE.  These  three  perspectives  are:  operational,  systems,  and  technical. 

5.1.1  Operational  Perspective 

The  operational  view  was  defined  as  that  of  users  of  the  synthetic  environments.  These  include 
commanders  of  forces  at  various  echelons,  the  staffs  who  provide  information  to  them, 
researchers,  analysts,  instructors,  and  trainers.  They  are  concerned  about  which  aspects  of  the 
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operational  forces  can  and  cannot  be  represented.  Of  those  aspects  represented,  they  are 
concerned  about  how  well  they  can  be  represented.  The  Army  subdivides  the  operational 
viewpoint  into  three  M&S  domains:  ACR,  RDA,  and  TEMO.  The  needs  for  SE  capabilities 
come  primarily  from  people  and  organizations  within  these  three  domains.  The  funding  to 
develop  and  provide  the  synthetic  environment  should  therefore  come  from  these  domains. 
STRICOM's  role  would  be  to  actively  solicit  funds  from  the  M&S  domains,  and  to  help  facilitate 
other  organizations  in  program  development.  STRICOM's  goal  would  be  to  oversee  the  SE  and 
provide  solutions  to  others'  M&S  needs.  In  that  role,  they  should  work  to  combine  needs  from 
multiple  sources  and  develop  common  technical  solutions.  The  result  would  be  lower  overall 
costs  to  the  organizations  involved  than  if  the  efforts  were  stand-alone  and  uncoordinated,  by 
cost  avoidance  through  synergy  and  reduction  of  duplication  by  programs.  It  would  also  be  an 
avenue  to  improving  the  SE. 

5.1.2  Systems  or  Program  Perspective 

The  second  view  is  the  systems  or  program  perspective,  which  is  that  of  the  program  managers 
who  are  responsible  for  particular  programs.  They  view  their  system  as  a  task  which  they  must 
accomplish.  These  are  the  people  who  have  and  control  the  funds.  As  senior  career  officers,  their 
performance  evaluation  is  based  on  completing  their  program  within  the  confines  of  its 
requirements,  schedule,  and  funding.  Currently,  investing  in  the  SE  may  even  conflict  with  the 
pressures  on  program  managers  to  conserve  their  funds  to  allow  for  unforeseen  occurrences. 

STRICOM’s  value  added  role  should  be  twofold:  1.  to  create  incentives  for  program  managers  to 
invest  in  the  SE  common  capabilities  and  recognize  how  this  change  may  impact  on  their 
ultimate  performance;  2.  for  development  of  common  capabilities,  find  a  way  to  generate, 
conserve,  or  allocate  the  working  capital  and  investment  capital  which  are  beyond  the  means  of 
the  programs  to  contribute.  To  gain  cooperation  from  the  program  managers,  STRICOM  also 
needs  to  become  an  entrepreneur  and  an  investor,  looking  for  opportunities  to  provide  cost 
avoidance  to  programs  by  developing  and  selling  SE  common  capabilities.  To  do  this, 

STRICOM  needs  a  valid  vision  of  the  common  capabilities  which  are  marketable  to  programs. 
This  report  addresses  the  identified  issues  and  plans  for  implementation.  Although  we  believe 
there  is  a  need  for  STRICOM  to  evolve  toward  a  new  business  approach,  we  have  not  attempted 
to  develop  a  corresponding  strategic  business  plan. 

5.1.3  Technical  Perspective 

The  technical  perspective  is  that  of  the  Army  and  contractor  engineers  who  are  tasked  with 
implementing  and  integrating  the  pieces  which  comprise  either  a  particular  system  or  the  SE  as  a 
whole.  This  is  the  level  at  which  we  have  prepared  the  individual  strategic  environment 
execution  plans  presented  in  this  report.  These  plans  address  how  to  utilize  the  enabling 
technologies,  and  how  to  develop  technical  solutions  to  the  identified  SE  issues. 

5.2  Overall  Strategy 

The  overall  strategy  for  STRICOM  to  improve  the  synthetic  environment  has  three  aspects: 

•  Funds 

•  Organization 

•  Contractual 
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5.2.1  Funds 

It  may  seem  too  obvious  to  need  stating,  but  funds  are  absolutely  necessary  to  accomplish 
anything.  Both  STRICOM  and  its  contractors  must  be  funded  to  perform  the  tasks  needed  to 
maintain  and  improve  the  SE  capabilities  and  infrastructure.  As  was  discussed  in  Section  5.1,  the 
current  funding  environment  places  control  of  the  vast  majority  of  the  funds  in  the  hands  of  the 
PMs.  Central  funding  of  the  SE  is  small  and  declining.  STRICOM  needs  to  develop  a  business 
strategy  to  raise  discretionary  working  capital  and  investment  capital  with  which  to  address  SE 
issues  in  a  more  centralized  way  on  behalf  of  the  Army. 

Another  way  to  provide  funding  to  improve  the  SE  is  to  develop  strategic  alliances  with 
TRADOC,  the  Program  Managers,  the  Program  Executive  Offices,  and  the  other  major 
commands  and  organizations  within  the  Army  Materiel  Command. 

5.2.2  Organization 

Implementing  the  recommendations  for  how  to  best  make  use  of  the  enabling  technologies 
requires  two  things: 

•  Access  to  technical  experts  who  understand  how  to  cost  effectively  apply  the  enabling 
technologies  within  and  across  programs.  This  expertise  can  reside  with  STRICOM,  its 
contractors,  other  Government  organizations,  or  across  a  combination  of  these. 

•  A  technical  manager  or  group  of  managers  with  the  desire,  ability,  and  the  authority  to 
take  analyses  and  recommendations  from  the  technical  experts,  consider  the  impact 
within  and  across  programs,  and  make  enforceable  decisions  relative  to  utilizing 
enabling  technologies  in  the  programs. 

Similarly,  addressing  the  identified  issues  and  achieving  synergy  in  solving  them  requires  two 
things: 

•  Access  to  technical  experts  who  understand  how  to  cost  effectively  implement 
solutions  to  these  issues.  This  can  be  a  combination  of  STRICOM  engineers,  contractor 
engineers,  and  the  Government  engineers. 

•  A  technical  manager  or  group  of  managers  with  the  desire,  ability,  and  authority  to  take 
analyses  and  recommendations  from  the  technical  experts,  consider  the  impact  within 
and  across  programs,  and  make  enforceable  decisions  about  implementing  solutions  in 
the  programs. 

Putting  these  organizational  recommendations  into  effect  is  needed  to  truly  address  and 
implement  solutions  to  the  identified  SE  issues. 

5.2.3  Contractual 

Consider  those  programs  for  which  STRICOM  is  the  contracting  intermediary  between  other 
Army  or  Government  organizations  and  defense  contractors.  A  different  pricing  strategy  by 
STRICOM  towards  the  funding  agency,  pricing  based  more  on  “value  to  the  agency,”  than  on 
simply  “cost  plus  loading,”  could  be  a  step  toward  “earning  a  profit”  which  could  be  used  to 
establish  and  build  up  working  capital  and  investment  capital. 
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Consider  the  contracts  that  STRICOM  issues  to  defense  contractors.  For  the  research  and 
development  types  of  programs,  a  cost  Plus  Award  Fee  (CPAF)  type  of  contract  provides 
STRICOM  and  the  agencies  providing  the  funding  with  the  maximum  leverage  to  enforce  proper 
use  of  the  enabling  technologies  and  designs  and  implementations  which  help  solve  the 
identified  SE  issues.  To  ensure  fairness  to  their  contractors  when  using  CPAF  contracts,  there 
must  be  realistic  evaluation  criteria.  Since  research  and  development  work  by  nature  has  a  level 
of  performance  uncertainty,  a  distinction  must  be  made  between  slow  progress,  because  the  task 
is  difficult,  and  under-performance  by  the  contractor. 

In  summary,  the  overall  strategy  to  improve  the  SE  involves: 

•  Acquiring  discretionary  working  capital  and  investment  capital 

•  An  organizational  structure  which  fosters  enforcement  of  good  SE  design  and 
implementation  decisions 

•  Contractual  policies  which  support  this  strategy. 

5.3  Evaluating  the  Choices 

This  report  summarizes  and  prioritizes  the  SE  issues  which  were  identified  by  the  interviewees. 

It  also  identifies  the  key  enabling  technologies  which  can  facilitate  addressing  the  SE  issues.  The 
questions  addressed  by  this  subsection  are: 

•  How  does  one  decide  which  issues  to  address? 

•  How  does  one  allocate  the  available  funding  among  those  issues? 

In  approximate  priority  order,  there  are  seven  key  factors  that  must  be  traded  off  in  trying  to 
answer  these  questions.  An  initial  assessment  of  high,  medium,  or  low  is  required  in  each 
instance  where  H,M,L  appear. 

•  What  is  the  priority  assigned  by  higher  level  commanders  to  solving  the  issue 
(H,M,L)? 

•  What  is  the  profile  of  the  discretionary  funding? 

•  What  is  the  potential  benefit  of  each  solutions  (H,  M,  L)? 

•  When  is  each  solution  is  needed? 

•  What  is  the  estimated  development  cost  and  profile? 

•  What  is  the  profile  of  available  funds  dedicated  to  the  specific  issue? 

•  What  is  the  development  risk  (funding,  schedule  and  technical)  for  each  issue 
(H,M,L)? 

The  ideal  issues  to  address  first  are  those  that  have  a  high  priority  assigned,  high  potential 
benefits,  low  development  risk,  are  needed  relatively  soon,  and  whose  development  cost  profile 
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is  satisfied  by  dedicated  funding.  The  issues  to  address  last  are  those  that  have  a  low  priority 
assigned,  low  potential  benefits,  high  development  risk,  are  not  needed  soon,  and  have 
insufficient  funding  available.  Most  issues  fall  somewhere  between  these  two  extremes. 

An  initial  priority  order  for  addressing  issues  can  be  arrived  at  by 

•  Assigning  a  weighting  to  each  of  the  factors  (e.g.,  1  to  5) 

•  Rating  each  issue  against  each  factor  (e.g.,  1  to  5) 

•  Computing  a  composite  weight  for  each  issue  as  the  sum  of  the  products  of  the 
weighting  factors  and  the  rating. 

This  is  not  an  exact  process,  but  it  is  a  straight-forward  way  to  apply  a  perspective  to  the  issues 
being  addressed.  The  final  priority  order  should  be  a  management  decision,  made  after 
consulting  with  the  affected  programs  and  the  technical  experts. 

5.4  Enabling  Technologies  Execution  Plans 

This  section  presents  recommended  courses  of  action  for  STRICOM  for  each  of  the  eight 
enabling  technologies:  architectures,  computers,  display  devices,  display  generators,  man 
machine  interfaces,  networks,  software,  and  tools. 

5.4.1  Architectures 

In  Section  4.3.1  architectures  at  three  levels  were  discussed:  the  architecture  of  the  overall  SE; 
the  architectures  of  the  CGFs,  SAFs,  manned  simulators,  and  the  C4I;  and  the  architecture  of  the 
software  running  within  each  computer. 

5.4.1. 1  Overall  SE  Architectures 

A  standard  architecture  for  the  SE  is  a  prerequisite  for  being  able  to  develop  systems  that  can 
interoperate  in  a  distributed  environment.  There  are  at  least  four  such  architectures  that  are 
important:  SIMNET,  DIS,  ALSP,  and  HLA.  SIMNET  was  the  first  widely  used  architecture, 
with  its  associated  interface,  protocol,  and  data  format  standards.  This  was  followed  by  DIS  and 
ALSP.  There  are  many  existing  SIMNET-compatible  simulators  in  use  today.  There  are  also 
many  DIS-compatible  simulators  in  existence,  and  others  under  development.  DIS  is  now  an 
IEEE  standard.  There  are  some  ALSP  simulations  in  existence,  but  a  smaller  number  than  for 
DIS.  The  newest  architecture  for  the  overall  SE  is  HLA.  DMSO  has  been  funding  and  promoting 
the  HLA.  Everyone  who  is  involved  with  DoD  M&S  is  aware  of  the  DoD’s  HLA  Mandate. 

What  should  STRICOM’ s  role  be?  First,  it  should  have  an  active  involvement  in  the  Architecture 
Management  Group  (AMG)  and  the  Architecture  Standards  Coordinating  Committee,  to 
participate  in  the  definition  and  standardization  of  architecture  for  the  SE.  Second,  it  should  have 
in-house  or  have  access  to  engineers  with  expertise  in  HLA,  HLA  tools  and  HLA  applications  to 
new  systems  and  to  legacy  systems.  Third,  it  should  ensure  that  the  current  systems  that  it  is 
developing  are  compatible  with  the  appropriate  SE  architecture  (DIS  and  HLA).  Fourth,  it  should 
be  pro-active  in  retrofitting  its  legacy  systems  (and  other's  systems)  with  HLA  compatibility. 

This  could  also  include  R&D  to  develop  interface  adapters  which  could  be  tailored  to  a  number 
of  different  legacy  systems. 
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5.4. 1.2  Architectures  of  CGFs,  SAFs,  and  Manned  Simulators 

Many  of  the  CGFs,  SAFs  and  manned  simulators  under  development  now  or  in  the  future,  are  or 
will  be  funded  through  STRICOM.  Examples  are  WARSIM  2000,  OneSAF,  and  CCTT. 
STRICOM  needs  to  have  in-house  or  access  to  (through  contractors  and  other  Government 
agencies)  systems  engineers  with  architectural  experience  and  expertise,  to  ensure  that  the  top 
level  architecture  of  each  system  is  appropriately  modular,  meets  appropriate  M&S  standards, 
will  be  interoperable  via  HLA,  and  can  be  maintained  and  upgraded  in  the  future. 

5.4. 1.3  Software  Architectures 

This  is  one  step  more  detailed  than  the  system  architecture  which  was  just  discussed.  There  is 
much  that  can  be  done  by  software  engineers  to  develop  software  with  good  overall  designs, 
appropriate  modularity,  and  that  can  be  maintained  and  upgraded  in  the  future.  STRICOM  needs 
to  actively  participate  in  the  design  reviews  of  its  projects,  especially  at  the  software  architecture 
and  software  design  levels,  to  ensure  that  these  objectives  are  being  achieved. 

5.4.2  Computers 

Army  M&S  is  a  user  of  computers.  The  commercial  market  drives  the  development  of 
computers.  STRICOM  should  carefully  track  what  is  happening  in  the  commercial  computer 
market,  and  try  to  use  mainstream  computers,  e.g.,  Pentium  microprocessors,  to  the  maximum 
extent  possible  in  its  projects.  This  requires  having  in-house,  or  readily  accessible,  persons  to 
perform  this  tracking  function  and  to  be  involved  in  STRICOM  projects  when  decisions  are 
being  made  about  what  computers  to  use. 

5.4.3  Display  Devices 

As  with  computers,  Army  M&S  is  a  user  of  devices  which  are  developed  by  the  commercial 
market.  STRICOM  should  track  the  commercial  market  and  ensure  what  is  proposed  for  use  in 
its  projects  makes  technical  and  economic  sense.  New  devices  may  open  up  possibilities  for 
improving  the  SE. 

5.4.4  Display  Generators 

The  comments  in  Section  5.4.3  also  apply  here. 

5.4.5  Man  Machine  Interfaces 

The  key  in  this  area  is  to  recognize  the  latest  technologies  as  they  are  developed.  The  Army 
should  not  be  in  the  business  of  developing  this  technology,  but  should  use  and  adapt  the 
technology  for  their  needs.  This  is  similar  to  the  sections  above,  where  the  commercial  market 
will  drive  the  technology  and  the  Army  applies  the  technology.  However,  unlike  computers, 
which  are  purchased  and  used  as  sold,  some  special  applications  may  have  to  be  developed  to 
ensure  optimal  use  of  the  product  for  the  simulation. 

5.4.6  Networks 

The  comments  in  Section  5.4.3  also  apply  here. 
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5.4.7  Software 

The  discussion  of  software  in  Section  4.3.7  addressed  five  areas:  operating  systems,  applications 
program  interfaces,  applications  and  models,  graphical  user  interfaces,  and  databases.  Comments 
on  these  areas  follow. 

5.4. 7.1  Operating  Systems 

Operating  systems  are  COTS  products.  The  comments  relative  to  computers  in  Section  5.4.2 
apply  also  to  computer  operating  systems,  i.e.,  go  with  the  mainstream  flow  in  the  commercial 
market. 

5.4. 7.2  Application  Program  Interfaces 

Net  cost  avoidance  across  STRICOM’s  programs  comes  from  designing  APIs  for  reuse.  This 
impacts  the  first  program  to  do  it,  but  there  are  accumulated  savings  when  other  programs  reuse 
the  APIs,  probably  with  minor  modifications.  STRICOM’s  role  should  be  to  ensure  the  original 
development  of  reusable  APIs,  and  then  foster  their  use  on  subsequent  programs. 

5.4. 7.3  Applications  and  Models 

STRICOM  can  achieve  life  cycle  cost  savings  within  each  of  its  programs  by  ensuring  that 
software  is  well  designed,  well  tested  at  appropriate  levels  in  its  development,  and  well 
documented.  This  involves  having  the  appropriate  level  of  technical  experts  and  oversight 
involved  in  the  specification,  design,  and  development  of  the  software  for  its  programs. 
Accumulating  additional  cost  avoidance  across  programs  can  occur  by  sharing  concepts,  designs, 
and  code  among  programs.  This  requires  having  some  people  who  work  across  program 
boundaries,  rather  than  having  each  individual  dedicated  to  a  specific  program. 

5.4. 7.4  Graphical  User  Interfaces 

Having  common  standards,  which  are  as  close  as  possible  to  commercial  GUI  standards,  will 
help  make  GUIs  more  intuitive,  easier  to  learn,  and  easier  to  use.  This  will  also  reduce  the 
training  time  required  for  users  who  know  one  simulation  to  leam  another  simulation. 
STRICOM’s  role  should  be  to  try  to  achieve,  to  the  extent  that  it  makes  sense,  a  common  look 
and  feel  to  the  GUIs  of  its  simulations. 

5.4. 7.5  Databases 

As  mentioned  in  Section  4.3. 7.5,  there  are  four  key  aspects  of  databases:  the  structure,  the 
process  of  preparing  raw  data  and  storing  it,  the  process  of  retrieving  the  stored  data,  and  the 
stored  data  itself.  Databases  are  used  for  storing  data  which  can  be  represented  in  tabular  or 
matrix  form.  For  smaller  tables  and  matrices  where  access  is  by  indexing,  standard  software 
constructs,  such  as  simple  arrays  and  arrays  of  structures,  will  probably  suffice.  Most  modem 
computer  languages  support  these.  For  databases  from  which  information  is  accessed  by  non- 
real-time  queries,  COTS  databases  probably  suffice.  For  databases  that  do  not  fit  these 
parameters,  it  is  likely  that  custom  databases  will  be  needed.  Probably  the  most  well  known 
example  of  this  is  the  terrain  database.  The  issues  related  to  terrain  databases  were  raised  in 
Section  4.2.1  and  discussed  further  in  Section  5.5.1. 

The  process  for  designing  application  specific  databases  is  done  by  engineers  who  are 
developing  specific  systems.  Cost  avoidance  occurs  when  an  existing  database  structure  (with  its 
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processes  for  preparing,  storing,  and  retrieving  data)  can  be  reused,  or  reused  with  minor 
modifications,  from  a  previous  system.  Further  cost  avoidance  occurs  when  database  contents 
can  be  reused,  or  reused  with  reformatting,  from  an  existing  database.  The  efforts  at 
standardizing  databases  are  intended  to  facilitate  this  reuse  with  its  subsequent  cost  avoidance 
and  schedule  advantages. 

STRICOM’s  role  relative  to  SNE  databases  is  discussed  in  Section  5.5.1.  For  STRICOM’s 
programs,  they  should  review  the  proposed  database  designs  and,  where  appropriate,  channel 
them  toward  reusing  existing  databases  and  their  contents. 

5.4.8  Tools 

There  are  two  broad  application  areas  for  tools  for  the  SE..  The  first  is  tools  that  are  used  in  the 
design,  development,  set-up,  and  analysis  of  a  simulation.  This  use  of  tools  is  primarily  for  the 
developer  and  the  simulation  user.  The  second  use  of  tools  is  for  the  program  manager.  In  this 
case,  the  tool  set  is  used  in  the  management  of  simulation  programs. 

STRICOM’s  role  would  be  to  identify  the  areas  where  tools  could  be  of  benefit  for  the 
developer,  the  user,  and  the  program  manager.  After  those  areas  are  identified,  the  tools  for  a  tool 
set  would  be  developed.  This  would  help  in  the  execution  of  current  simulations.  It  would  also 
help  the  development  and  management  of  new  simulation  programs. 

As  with  computers,  display  devices,  and  display  generators,  STRICOM  should  carefully  track 
what  is  happening  in  the  commercial  market.  Many  software  companies  are  developing 
applicable  tool  sets.  STRICOM  should  try  to  use,  and  encourage  its  contractors  to  use,  COTS 
tools  to  the  maximum  extent  possible.  The  strategy  for  developing  custom  tools  is  discussed  in 
Section  5.5.7. 

5.5  Identified  Issues  Execution  Plans 

This  section  describes  recommended  courses  of  action  for  each  of  the  seven  categories  of  issues 
discussed  in  Section  4.2:  SNE,  representation  of  behaviors,  interoperability,  reconfigurability, 
C4I,  numbers  of  entities,  and  tools. 

5.5.1  Synthetic  Natural  Environment 

There  is  considerable  work  that  needs  to  be  accomplished  in  this  area.  All  of  the  models  in 
Figure  3  SNE  Interactions  can  use  extension  and,  in  some  cases,  development.  There  needs  to  be 
an  authoritative  representation  of  the  natural  environment  and  a  common  technical  framework. 

The  authoritative  representation  of  the  natural  environment  can  be  described  as  models  of 
operations.  Those  models  depend  on  interaction  with  representations  of  the  natural  environment. 
This  includes  interaction  with  permanent  and  semi-permanent  man-made  features,  realistic 
representations  of  weapons  effects,  and  the  resulting  environment.  To  accomplish  this  requires 
four-dimensional  (the  fourth  dimension  is  time)  terrain,  ocean,  atmosphere,  and  space 
environmental  models.  When  developing  these  models,  they  must  be  seamless  to  present  a  fully 
integrated  data  set  for  M&S  use. 
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The  terrain  representation  includes  configuration,  composition,  and  representation  of  the  surface 
of  the  earth.  Also  included  in  the  terrain  is  the  variation  that  occurs  with  the  seasons,  (e.g.,  grass 
and  snow  cover,  leaves  and  barren  trees,  shadows  and  sun). 

For  the  ocean  representation,  features  such  as  ocean  bottom,  whether  natural  or  man-made,  must 
be  considered.  Other  characteristics  to  be  considered  include  temperature,  pressure,  salinity  and 
acoustic  phenomena. 

The  atmospheric  representations  must  be  developed  from  the  earth’s  surface  to  space.  In  addition 
to  the  standard  atmospheric  domain,  particle  and  aerosol  effects  must  be  included.  This  also 
includes  nuclear,  biological,  and  chemical  effects.  Other  traditional  weather  parameters,  like  fog, 
clouds,  precipitation,  temperature,  pressure,  and  winds,  must  also  be  considered. 

The  space  representations  are  needed  for  the  processes  that  affect  satellite,  spacecraft,  and 
missile  performance.  Some  of  these  conditions  are  natural  in  origin,  such  as  a  solar  flare.  Others 
are  man-made.  In  either  case,  changes  in  the  geomagnetic  field  and  charged  particles  must  be 
accurately  portrayed. 

To  address  model  and  data  inter-usage  needs,  most  respondents  stated  a  need  to  continue  the 
development  of  HLA  and  SEDRIS.  Both  of  these  were  looked  at  as  means  to  efficiently  and 
effectively  share  resources.  HLA  compliance  would  allow  individual  models  to  federate  and 
become  part  of  a  larger  simulation.  By  using  a  common  data  interchange  format,  SEDRIS,  the 
long-standing  proprietary  databases  that  have  been  developed  would  be  useful  for  more  than  one 
program.  Any  new  databases  and  the  subsequent  simulations  would  develop  Application 
Program  Interfaces  (APIs)  to  allow  for  the  easy  interchange  of  data  in  the  SEDRIS  format.  These 
two  efforts  would  allow  reuse  and  enable  greater  cost  avoidance  in  the  future. 

Another  outcome  of  developing  higher  fidelity  models  that  use  a  common  format,  is  consistency 
among  simulations.  Similar  models,  if  not  the  same  ones,  could  be  used  both  in  the  training 
environment  and  for  mission  rehearsal. 

STRICOM’s  role  should  be  in  three  areas.  First,  fund  the  development  of  higher  fidelity  models. 
Next,  continue  to  support  HLA  integration  and  compliance.  Finally,  make  SEDRIS  the 
interchange  standard  and  ensure  SEDRIS  matures  to  meet  the  increasing  needs  of  the  M&S 
community. 

5.5.2  Representation  of  Behaviors 

Of  the  seven  categories  of  issues  that  were  identified  in  the  interviews,  the  representation  of 
behaviors  is  a  category  which  is  truly  a  research  topic,  and  will  require  a  research  approach.  The 
other  categories  of  issues  are,  for  the  most  part,  amenable  to  engineering  solutions.  A  research 
approach  means  that  the  answers  are  not  known,  and  it  will  take  technological  or  intellectual 
breakthroughs  to  find  workable  answers.  For  engineering  solutions,  on  the  other  hand,  the 
answers  are  usually  known,  the  problems  to  be  solved  to  attain  those  answers  are  usually  easily 
identified,  and  reasonable  plans  of  attack  are  usually  readily  defined  and  followed  to  implement 
the  answers.  The  strategy  here  would  be  to  solicit  and  fund  a  variety  of  promising,  but  usually 
high  risk,  ideas. 


37 

Use  or  disclosure  of  information  on  this  page  is  subject  to  the  restrictions  referenced  on  cover  of  this  report. 

UNCLASSIFIED 


ADST-II-CDRL-SESP-9800 1 92 
7/15/98 


By  dissecting  the  problem  into  smaller  pieces  and  attacking  those  pieces,  some  specific  solutions 
can  be  found  more  quickly  than  by  seeking  a  general  solution  to  the  entire  problem  area.  For 
example,  we  can  divide  Army  operations  into  three  classes  of  scenarios: 

•  Open  Battlefields, 

•  Urban  Warfare,  and 

•  Support  and  Security  Operations  (formerly  Operations  Other  Than  War) 

Subdividing  the  solution  leads  to  the  following: 

•  Descriptions  of  Behaviors  (e.g.,  word  descriptions,  such  as  a  psychologist  or 
sociologist  might  use;  doctrinal  behaviors,  as  described  in  Army  manuals;  doctrinal 
behavior,  as  described  in  joint,  coalition,  or  opposing  forces  (OPFOR)  manuals; 
descriptions  of  cultures,  etc.). 

•  Frameworks  for  Representing  Behaviors  (i.e.,  conceptual  structures  which  (1)  can  be 
used  to  represent  a  class  or  classes  of  behaviors,  and  (2)  are  amenable  to  processing  by 
computer  programs). 

•  Representations  of  Behaviors  within  the  Frameworks  (i.e.,  populating  frameworks  with 
appropriate  data  which  represents  specific  behaviors). 

The  logical  place  to  begin  is  the  open  battlefield  scenarios,  which  is  the  focus  of  current  SAFs 
and  CGFs.  Assemble  documentation  on  the  available  training  and  fighting  doctrines  for  each 
echelon  of  forces,  starting  from  the  individual  soldier  and  working  up  to  platoons,  companies, 
brigades,  etc.  Keep  the  viewpoint  as  modular  as  possible,  by  defining  non-overlapping  entity 
types  within  each  echelon.  Examples  of  entities  at  the  individual  soldier  level  are  tank  driver, 
gunner,  and  tank  commander.  Examples  of  entities  at  a  group  with  vehicle  level  are  tank  with 
crew,  armored  personnel  carrier  with  crew,  and  helicopter  with  crew. 

Now  choose  an  easy  example,  such  as  ground  vehicles,  and  choose  a  type,  like  a  refueling  truck. 
Next  find  an  astute  operations  person  who  knows  the  doctrine  and  has  experience  in  the 
environment.  Team  him  or  her  with  a  creative  modeler  and  an  experienced  software  engineer. 
The  assignment  for  this  team  would  be  to  develop  the  best  framework  they  can  for  describing  the 
behaviors,  as  functions  of  the  battlefield  environment.  Next  have  them  populate  the  framework 
with  the  behavioral  data.  This  is  an  iterative  process.  When  this  simple  vehicle  has  been  done 
satisfactorily,  repeat  for  another  type  of  vehicle,  working  from  what  is  seemingly  the  easiest 
toward  the  most  difficult.  Continue  as  long  as  good  progress  is  being  made. 

Repeat  (perhaps  in  a  parallel  or  overlapping  fashion)  for  other  classes  of  entities,  such  as  fighting 
vehicles  with  crews,  squadron  commanders,  company  commanders,  etc.  Start  with  what  seems  to 
be  the  easiest  and  work  toward  the  most  difficult  type  of  behavior. 

Each  time  a  team  stops  because  the  problem  is  too  difficult,  there  is  a  need  for  research  to  find  a 
solution.  The  research  effort  and  funding  should  probably  be  focused  simultaneously  in  two 
directions:  (1)  toward  lower  difficulty  (lower  risk)  problems  whose  solutions  would  provide  a 
reasonable  to  high  return  on  funds  invested,  and  (2)  toward  high  difficulty  (higher  risk)  problems 
whose  breakthroughs  would  significantly  improve  M&S  capabilities. 
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5.5.3  Interoperability 

Conducting  distributed  simulations  presupposes  that  the  components  of  the  simulation  can 
interoperate.  That  is,  they  can  communicate  (send  and  receive  data  and  interact  with  appropriate 
time  synchronization)  information,  such  as  position,  orientation,  velocity,  sensor  detections, 
weapons  firings,  etc.  (Radio  communications  between  players  is  discussed  in  Section  5.5.5  C4I). 

Referring  to  Figure  1,  we  can  readily  imagine  that  achieving  interoperability  requires 
compatibility  on  several  levels.  The  first  level  is  the  ability  to  successfully  send  and  receive  data 
via  the  Interconnections  function.  This  requires  signal  level  compatibility,  easily  achieved  using 
COTS  LANs,  WANs,  modems,  etc.  It  also  requires  protocol  compatibility,  also  easily  achieved 
using  COTS  network  software. 

The  second  level  of  compatibility  is  the  data  structure  and  format  of  the  messages  which  are  sent 
and  received.  All  participants  in  the  simulation  must  understand  and  be  able  to  encode  into  and 
decode  from  the  permissible  message  formats. 

The  third  level  of  compatibility  is  to  understand  the  meanings  of  messages  received. 
Interoperability  is  never  achieved  accidentally  or  through  good  fortune.  It  is  only  achieved  by 
deliberate  actions.  These  actions  generally  fit  into  one  of  three  strategies:  designing  for 
interoperability  (by  agreeing  a  priori  on  protocols  and  formats);  inserting  (perhaps  preceded  by 
developing)  translators  (gateways)  between  dissimilar  protocols,  formats  and/or  systems;  and 
retrofitting  interoperability  capabilities  into  previously  non-interoperable  systems.  Currently, 
there  is  active  work  going  on  within  all  three  of  these  strategies. 

5.5.3.1  Designing  For  Interoperability 

Earlier  examples  of  this  are  simulators  that  were  designed  to  interoperate  via  the  SIMNET, 
simulators  and  simulations  designed  to  interoperate  via  the  DIS,  and  simulations  designed  to 
interoperate  via  the  ALSP.  Current  examples  include  simulators  and  simulations  being  built  to  be 
DIS  compatible,  and  simulators  and  simulations  being  designed  or  built  to  be  HLA  compatible. 

5.5.3.2  Inserting  Translators 

One  example  of  this  is  the  Operational  State  Interpreter  (OPSIN)  that  performs  aggregation,  de¬ 
aggregation,  and  message  translation  between  Brigade/Battalion  Battle  Simulation  (BBS)  and 
ModSAF.  Another  is  a  gateway  that  performs  protocol  translation  between  a  DIS  simulator  and 
an  HLA  network. 

5. 5. 3. 3  Retrofitting  Interoperability  Capabilities 

Earlier  examples  of  this  are  stand-alone  simulations  that  were  retrofitted  with  DIS  capabilities. 
Current  examples  are  simulators  and  simulations  that  are  being,  or  are  planned  to  be,  retrofitted 
to  be  HLA  compatible. 

This  area  of  interoperability  falls  into  the  domain  of  engineering  (and  economical)  solutions.  It  is 
entirely  achievable,  however,  achieving  interoperability  for  any  particular  simulator  or 
simulation  may  or  may  not  be  economically  attractive. 
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STRICOM  should  take  a  major  leadership  role:  (1)  as  a  developer  of  methods  and  tools  for 
designing  to  HLA  standards,  (2)  as  a  developer  of  HLA  translators  for  existing  systems,  (3)  as  a 
developer  of  methods  and  tools  for  retrofitting  HLA  into  existing  systems,  (4)  as  a  focal  point  for 
overseeing  new  designs  for  HLA  compatibility,  (5)  as  a  focal  point  for  assisting  in  incorporating 
translators  into  existing  systems  and  (6)  as  a  focal  point  for  overseeing  and  contracting  (on 
behalf  of  others)  for  retrofitting  HLA  into  existing  systems. 

This  requires  up-front  funding  for  development  of  tools,  methods  and  translators.  It  requires 
technical  expertise  in  architectures,  standards,  systems  engineering,  hardware,  and  software  on 
the  part  of  STRICOM  engineers,  its  contractors,  or  a  combination  of  both.  It  also  requires  a  focus 
on  selling  STRICOM  and  its  contractors  to  the  funding  sources  as  value  added  providers  who 
can  do  the  job  cheaper,  faster,  and  better  than  if  the  others  try  to  do  it  themselves  or  with  their 
contractors. 

5. 5.3.4  Terrain 

One  other  major  aspect  of  achieving  interoperability  relates  to  the  terrain  database.  There  must 
be  a  correlation  in  elevation  between  the  terrain  representations,  or  else  ground  vehicles  may 
appear  to  float  in  the  sky,  be  out  of  view  below  the  ground,  or  have  different  intervisibilities 
(vehicle  A  can  see  Vehicle  B,  but  not  vice  versa).  The  latter  prevents  conducting  a  fair  fight.  The 
former  prevents  effective  gunnery. 

Lack  of  terrain  elevation  correlation  between  visual  systems  and  C4I  systems  results  in  cases 
where  two  vehicles  are  mutually  visible,  but  can’t  communicate  in  the  simulator  with  line  of 
sight  radios,  or  where  two  vehicles  are  not  mutually  visible,  but  can  communicate  in  the 
simulation  with  line  of  sight  radios.  Neither  case  is  correct. 

These  simulation  anomalies  due  to  uncorrelated  terrain  elevation  representations  have 
engineering  solutions.  Actually  implementing  the  solutions  is  primarily  a  funding  issue.  It  may 
be  very  costly  to  change  the  terrain  representations  in  the  affected  simulators,  simulations,  and 
radios. 

5.5.3. 5  M&S  Interchange  Format 

A  major  step  toward  achieving  interoperability  between  systems,  simulators,  and  simulations 
would  be  to  have  a  common  data  interchange  format.  STRICOM  has  already  invested  significant 
resources  into  developing  SEDRIS  for  this  purpose.  Using  SEDRIS  as  the  data  interchange 
format  can  facilitate  interoperability,  because  both  the  producer  and  the  consumer  of  data  can 
develop  standard  APIs  for  inputting  and  outputting  data  in  the  SEDRIS  format.  Over  the  long 
term,  this  will  facilitate  reuse  of  data.  It  will  also  help  to  steer  the  M&S  community  away  from 
proprietary  solutions  and  unique  databases. 

5.5.4  Reconfigurability 

The  comments  in  this  category  related  to  two  aspects  of  reconfigurability: 

•  Multipurpose  simulators,  and 

•  Reprogrammable  simulators 
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5.5.4.1  Multipurpose  Simulators 

The  main  reason  for  wanting  multipurpose  simulators  is  to  reduce  the  acquisition  and 
maintenance  costs  of  having  different  simulators  for  different  purposes.  Suppose  there  is  a  need 
for  50  Ml  A2  tank  driver  simulators  for  training  purposes  on  day  one,  50  Ml  A1  gunnery 
simulators  on  day  two,  50  M2A2  driver  simulators  on  day  three,  and  50  M2A2  gunnery 
simulators  on  day  four.  This  could  come  from  training  needs  or  to  conduct  an  experiment.  The 
acquisition  cost  question  is  this:  should  the  Army  develop  and  procure  200  individual  task 
trainers  (50  M1A2  drivers,  50  M1A2  gunnery,  50  M2A2  driver,  and  50  M2A2  gunnery),  100 
Option  #1  multiple  task  trainers  (50  Ml  A2  dual  task  trainers  and  50  M2A2  dual  task  trainers), 
100  Option  #2  multiple  task  trainers  (50  reconfigurable  driver  trainers  and  50  reconfigurable 
gunnery  trainers),  or  50  fully  reconfigurable  trainers  that  can  be  configured  for  any  of  the  four 
tasks?  In  other  words,  is  it  more  economical  to  acquire  and  maintain  200  individual  task  trainers, 
100  dual  task  trainers,  or  50  multitask  trainers?  The  answer  depends  on  the  degree  to  which  the 
simulator  should  replicate  the  look  and  feel  of  the  vehicle.  An  earlier  generation  of  soldiers 
probably  preferred  a  simulator  that  replicated  the  look  and  feel  of  the  actual  vehicle.  The  current 
generation  and  upcoming  generations  of  soldiers  grew  up  playing  video  games.  They  do  not  need 
to  walk  into  a  simulator  to  be  trained.  The  current  generations  can  suspend  belief  in  front  of  a 
video  screen  and  shoot  aliens  first,  drive  a  motorcycle  next,  fly  an  F-16,  and  then  fight  a  Kung- 
Fu  opponent.  For  them,  functionality  is  important,  and  the  look  and  feel  of  the  controls  is  a  non¬ 
issue.  For  the  current  and  for  upcoming  generations  of  soldiers,  reconfigurable  simulators  are 
highly  feasible. 

A  major  impediment  to  developing  multipurpose  simulators  is  the  way  they  are  funded.  Suppose 
it  is  desirable  to  have  a  multivehicle  driver  training  simulator  that  supports  Bradley  A3, 

Crusader,  and  Grizzly.  To  be  fair  to  each  program,  they  should  all  contribute  to  the  common 
development.  Since  the  Bradley  A3  vehicle  is  much  further  along  in  its  development,  it  has  a 
need  for  simulators  well  before  Crusader  or  Grizzly.  We  can  make  the  reasonable  assumption 
that  a  multipurpose  simulator,  designed  for  reconfigurability,  will  cost  somewhat  more  and  take 
somewhat  longer  to  develop  and  field  than  a  single-purpose  simulator.  Where  does  the  extra 
funding  and  the  extra  schedule  time  come  from?  The  extra  schedule  time  has  to  be  factored  into 
the  Bradley  program.  The  extra  funding  should  come  from  Crusader  and  Grizzly.  Ideally  the 
three  PMs  should  work  cooperatively  on  developing  the  simulator.  A  role  for  STRICOM  would 
be  to  broker  the  deal  and  be  the  lead  in  developing  the  simulator.  It  has  been  this  type  of 
unresolved  scheduling  and  funding  issues  that  have  contributed  to  the  current  situation  of  so 
many  stovepipe  simulators. 

5. 5.4.2  Reprogrammable  Simulators 

The  second  aspect  of  reconfigurability  is  reprogrammable  simulators:  that  is  simulators  whose 
software  is  easily  modified.  This  is  important  for  two  reasons.  First,  the  simulator  models  a  real 
vehicle  and  when  the  real  vehicle’s  characteristics  are  modified  or  upgraded,  the  simulator 
should  be  modified  to  reflect  the  new  properties.  Second,  the  Army,  particularly  the  ACR 
domain,  investigates  the  effects  of  adding  new  capabilities  to  vehicles.  There  is  the  need  to 
simulate  these  proposed  capabilities  and  investigate  their  effects  on  the  outcome  of  various 
scenarios  and  missions. 
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Achieving  reprogrammability  is  an  engineering  solution.  It  is  achievable  through  modular 
software  design.  Designing  for  reprogrammability  takes  longer  and  initially  costs  more.  It  also 
requires  more  documentation  of  the  design,  the  implementation,  and  the  software  development 
tools.  Although  the  likely  result  is  lower  life  cycle  costs  through  easier  software  maintenance, 
achieving  easy  reprogrammability  requires  more  upfront  expenditures  and  a  longer  initial 
development  time.  Since  program  managers  have  always  focused  on  reducing  development  costs 
and  schedule  time  for  their  particular  program,  it  will  be  necessary  to  find  incentives  to  have 
them  give  equal  focus  to  life  cycle  cost  and  reusability. 

5.5.5  C4I 

Two  categories  of  issues  were  identified  relative  to  C4I: 

•  Representation  of  communication  networks,  bandwidth,  and  loading,  and 

•  Integration  of  C4I  systems  with  the  SE. 

5.5.5.1  Representation  of  Communications  Networks 

The  division  of  labor  for  this  is  very  straightforward.  Since  the  U.S.  Army  Communications  and 
Electronics  Command  (CECOM)  has  the  knowledge  of  and  responsibility  for  Army  operational 
communication  systems,  CECOM  should  have  the  responsibility  for  modeling  the 
communications  systems.  Since  STRICOM  has  the  knowledge  of  and  responsibility  for  the 
simulations,  STRICOM  should  have  the  responsibility  for  taking  those  models  and  implementing 
them  in  the  simulations.  For  the  maximum  benefit  of  everyone  involved  (CECOM,  STRICOM, 
the  budget,  and  the  M&S  end  users)  this  should  be  a  cooperative  effort.  By  working  together  on 
STRICOM’s  model  needs,  CECOM  can  better  deliver  what  is  needed  without  expending  money, 
effort,  and  time  in  developing  unnecessary  capabilities  or  resolution.  Furthermore,  collaboration 
can  result  in  user  interfaces  which  are  more  intuitive  and  easier  to  use. 

STRICOM  should  also  work  with  CECOM  to  develop  models  that  more  easily  interface  into  the 
various  simulators  and  simulations.  STRICOM’s  role  would  be  implementing  these  models  into 
the  simulators  and  simulations. 

Good  planning  and  cooperation  between  CECOM  and  STRICOM  would  reduce  the  number  of 
unique  models  needed,  reduce  the  number  of  unique  interfaces  needed,  increase  the  commonality 
and  reuse  of  software  components  in  the  models  and  interfaces,  and  result  in  more  nearly  optimal 
functionality,  while  reducing  total  development  costs  and  life  cycle  costs  for  the  models  and  their 
interfaces. 
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5.5.5.2  Integration  of  C4I  Systems  with  the  SE 

Lets  begin  by  discussing  two  systems  communicating  with  each  other  as  shown  in  Figure  5.  We 
are  assuming  a  bi-directional  communication  path.  This  is  the  general  case  of  two  unidirectional 
communication  paths  (one  from  A  to  B,  the  other  from  B  to  A).  The  two  interfaces  are 
specifically  indicated  to  aid  this  discussion. 


Interface 

^  Communication 

Interface 

System  B 

System  A 

A 

*  Path  * 

'  B 

(Rxjx) 

(Rx,  Tx) 

Figure  5.  Two  Systems  Communicating 

For  System  A  to  send  a  message  to  System  B,  it  first  prepares  the  message  and  encodes  it  in  a 
predetermined  format.  The  message  is  transferred  to  Interface  A,  which  uses  a  predetermined 
protocol  to  put  the  message  onto  the  communication  path  (radio  link,  point-to-point  wiring, 
commercial  telephone  circuit,  etc.).  The  protocol  must  be  such  that  Interface  B  can  detect  the 
presence  of  an  incoming  message  and  know  to  capture  it,  as  well  as,  how  to  capture  it.  Interface 
B  alerts  System  B  that  it  has  received  a  message  and,  upon  request,  can  transfer  that  message  to 
System  B.  Once  requested  and  received,  System  B  decodes  the  message,  perhaps  interprets  it, 
and  can  act  upon  the  message.  Based  on  knowing  the  predetermined  format,  System  B  can  then 
send  a  reply  or  response  message  to  System  A  in  the  same  manner. 

The  above  series  of  operations  is  very  straightforward  if: 

•  System  A  and  System  B  understand  and  adhere  to  an  agreed  upon  message  format 

•  System  A  is  compatible  with  Interface  A,  and  System  B  is  compatible  with  Interface 
B 

•  Interface  A  and  Interface  B  understand  and  adhere  to  an  agreed  upon  communications 
protocol 

•  Interface  A  and  Interface  B  and  their  protocols  are  compatible  with  the  Communication 
Path. 

These  four  conditions  must  be  met  by  the  designs  of  any  two  systems  that  intend  to 
communicate.  This  is  always  achievable  when  the  two  systems  are  identical.  However,  a  major 
problem  occurs  when  trying  to  interface  C4I  systems  to  models  and  simulations  that  were  not 
designed  to  communicate  with  each  other.  Currently,  no  one  intends  to  redesign  or  modify 
existing  C4I  systems  to  make  them  compatible  with  simulations.  Also,  no  one  intends  to  modify 
existing  C4I  systems  to  make  them  easier  to  interface  with  simulations.  Finally,  it  is  unlikely  that 
C4I  systems  being  designed  now  will  do  this  either.  Therefore,  the  full  burden  of  developing 
ways  for  C4I  to  interoperate  with  simulations  in  the  SE  has  fallen  upon  those  responsible  for 
building  the  SE. 
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The  general  solution  for  getting  two  dissimilar  systems  to  communicate  is  shown  in  Figure  6, 
where  an  Adapter  Unit  (AU)  is  placed  between  the  two  systems.  System  A  communicates  with 
the  Adapter  Unit  using  System  A's  message  communication  format  and  protocol.  The  AU 
translates  the  message  into  System  B’s  format  and  sends  it  to  System  B  using  the  System  B 
protocol. 


Figure  6.  Adapter  Unit  Interfaces  Between  Dissimilar  Systems 


System  B  sends  messages  to  System  A  in  a  similar  manner,  with  the  AU  translating  the  message 
from  System  B’s  format  to  System  A’s  format.  The  degree  of  difficulty  for  developing  this  AU 
depends  on  the  similarity  of  the  System  A  and  B  message  formats  and  contents,  and  on  the 
specific  interfaces  that  Systems  A  and  B  use. 

Many  unique  adapter  units  have  been  prototyped  to  interface  a  specific  C4I  system  to  a  specific 
simulator  or  simulation.  Some  have  been  bi-directional;  others  have  been  uni-directional.  There 
have  been  efforts  to  develop  a  more  general  adapter  unit  which  could  interface  to  a  number  of 
systems.  One  example  is  the  Modular  Reconfigurable  C4I  Interface  (MRCI),  whose  objective 
was  to  interface  a  number  of  different  C4I  systems  to  the  HLA  Run  Time  Infrastructure  (RTI). 
Referring  to  the  AU  in  Figure  6,  the  Interface  B  is  the  HLA  RTI  and  System  A  is  the  target  C4I 
system.  MRCI’s  design  strategy  was  to  have  interchangeable  versions  of  Interface  A,  and 
tailorable  software  modules  in  the  translator.  This  is  a  valid  strategy.  The  implementation  of  an 
adapter  unit  may  not  be  fully  achievable  without  some  modification  to  System  A’s  message 
format  and  contents.  Such  modifications  may  be  needed,  for  example,  to  provide  additional  data 
needed  by  System  B,  or  to  better  allow  System  B  to  distinguish  between  System  A  message 
types.  Since  the  operational  C4I  systems  are  unlikely  to  be  changed  to  accommodate  this,  an 
adapter  unit’s  functionality  may  be  limited  to  a  subset  of  the  full  message  set. 

Another  strategy  for  interfacing  multiple,  dissimilar  systems  is  shown  in  Figure  7.  In  this 
example  there  are  separate  adapter  units  which  translate  each  system’s  message  into  a  common 
format.  The  messages  are  then  sent  and  received  over  a  common  network  or  communication 
path.  This  quickly  becomes  a  much  superior  solution  to  A-to-B  Adapter  Units  when  the  number 
of  dissimilar  systems  increases. 


Common  Path  Protocol,  and  Format 


Figure  7.  Adapting  To  A  Common  Protocol  And  Format 
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For  instance,  the  Common  Interface  could  be  an  Ethernet  port,  the  Common  Path  could  be  an 
Ethernet,  the  Common  Protocol  could  be  TCP/IP,  and  the  Common  Format  is  yet  to  be  defined. 
However,  an  excellent  candidate  for  the  common  format  is  the  Joint  Technical  Architecture 
(JTA),  which  is  a  draft  set  of  standards  intended  to  help  solve  the  C4I  interoperability  issues.  To 
the  degree  that  operational  C4I  systems  migrate  toward  JTA  to  achieve  operational 
interoperability,  the  adapter  units  become  easier  to  develop. 

The  optimum  long-term  solution  from  the  M&S  viewpoint  is  for  C4I  systems  to  have  a  separate 
input/output  (I/O)  port  which  can  be  used  for  testing  during  system  development,  manufacturing, 
and  maintenance  and  as  an  I/O  port  which  can  directly  (or  via  a  low  cost  interface  adapter) 
interface  with  the  SE.  The  SE  or  a  stimulator  could  stimulate  the  C4I  system  via  this  port,  and 
the  C4I  system  could  provide  outputs  to  the  SE.  A  convenient  format  from  the  M&S  perspective 
would  be  SEDRIS.  The  C4I  system  would  translate  its  I/O  based  on  the  SEDRIS  format,  thus 
making  it  readily  usable  by  multiple  M&S  systems. 

There  are  at  least  four  distinct  cases  for  integrating  C4I  systems  with  the  SE: 

•  Simulation  of  C4I  systems,  to  provide  data  to  the  SE, 

•  Stimulation  of  real  C4I  systems,  to  provide  data  to  the  SE, 

•  Interfacing  between  range  systems  and  the  SE,  and 

•  Interfacing  between  live  players  and  the  SE. 

5.5.5.2.1  Simulation  of  C4I Systems 

The  simulation  of  C4I  systems  ranges  from  a  device,  such  as  a  SINCGARS  Radio  Emulator  at 
the  low  end  to  simulation  of  the  image  from  an  unmanned  aerial  vehicle  (UAV)  at  the  high  end. 
There  is  probably  not  a  general  solution  for  modeling  C4I  devices,  however,  the  architectures 
shown  in  Figures  5,  6,  and  7  are  all  appropriate  for  interfacing  C4I  simulations  into  the  SE. 

5.5.5. 2.2  Stimulation  of  Operational  C4I  Systems 

Operational  C4I  systems  which  are  interfaced  to  the  SE  could  be  stimulated  to  provide  data  to 
the  SE.  Such  systems  range  from  the  Single  Channel  Ground  Air  Radio  System  (SINCGARS) 
radios  at  the  low  end  to  JSTARS  ground  stations  at  the  high  end.  There  is  a  straightforward  set  of 
steps  to  approach  this: 

•  Determine  the  desired  outputs  from  the  C4I  devices 

•  Determine  the  required  inputs  to  cause  those  outputs 

•  Determine  how  to  generate  these  inputs  (e.g.,  record  an  audio  tape  and  use  a  tape  player 
for  voice,  record  a  video  tape  and  use  a  video  tape  player  for  imagery,  create  on-line 
computer  generated  imagery,  such  as  a  Stealth  display) 

•  Determine  how  to  interface  those  inputs  into  real  C4I  system 

•  Implement  the  solution. 

5.5.S.2.3 Interfacing  with  Range  Systems 

Range  systems  typically  capture  outputs  from  large  numbers  of  players  in  an  exercise.  For 
instance,  there  are  simultaneous  voice  transmissions  on  a  number  of  radio  frequency  channels. 
There  is  also  periodic  position  reporting  by  each  of  the  vehicles  involved  in  the  exercise.  There 
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can  be  video  transmissions.  Voice  must  be  tagged  with  its  transmission  frequency  or  channel 
number  when  it  is  provided  to  the  SE.  Compatible  radios  or  radio  emulators  in  the  SE  must  be 
able  to  set  their  receive  frequency  or  channel  number,  and  access  a  particular  voice  net.  Vehicle 
position  data  must  be  translated  into  a  format  understandable  by  the  SAFs  or  CGFs  in  the  SE. 
Video  transmissions  could  be  channeled,  as  with  cable  TV.  They  could  then  be  selected  and 
viewed  by  live  players  in  the  SE,  who  have  tuners  and  video  displays. 

It  may  also  be  required  to  provide  data  from  the  SE  back  to  range  systems.  This  could  occur  in 
an  exercise  with  live  vehicles  and  players  in  a  small  area  of  the  simulated  battlefield,  with  a 
larger  friendly  virtual  force  on  each  side  and  a  virtual  opposing  force.  This  is  the  same  as  Case  2 
-  Stimulation  of  Operational  C4I  systems,  where  the  scenario  running  in  the  SE  must  be  used  to 
provide  correctly  formatted  information  to  the  C4I  systems,  e.g..  Applique,  in  the  live  vehicles. 
Surrogates  are  often  the  most  economical  way,  at  this  time,  to  provide  the  SE  generated  voice 
and  message  traffic  (e.g.,  commands  downward  and  reports  upward). 

5.5.S.2.4 Interfacing  with  Live  Players 

There  are  three  primary  ways  to  communicate  with  live  players:  voice,  messages,  and  imagery. 
Voice,  messages,  and  imagery  from  a  live  player  require  that  the  live  player's  C4I  device  (e.g., 
SINCGARS,  Applique,  etc.)  be  interfaced  into  the  SE.  This  has  already  been  discussed. 
Currently,  to  provide  voice  to  a  live  player  requires  a  live  player  in  the  SE  to  generate  that  voice. 
Messages  (e.g.,  commands  or  situation  reports)  can  be  provided  to  the  live  player  either  from 
another  live  player  or  through  an  interface  with  the  SE.  Imagery  can  be  provided  from  pre¬ 
recorded  video  tapes  or  from  on-line  computer  generated  imagery,  such  as  a  Stealth  display. 

5.5.6  Numbers  of  Entities 

There  can  be  a  high  cost  for  conducting  a  large  simulated  battle.  Therefore,  the  approach  to 
increase  the  number  of  entities  must  be  balanced  between  the  cost  and  the  desired  degree  of 
realism.  There  are  several  approaches  to  increasing  the  numbers  of  entities  in  simulated  battles. 
One  is  to  use  additional  live  entities  (ground  vehicles  and  aircraft)  at  a  test/training  range  and 
link  them  into  the  SE.  This  approach  incurs  a  high  cost  for  each  simulated  battle.  A  second  high 
cost  approach  is  to  procure  additional  copies  of  high  fidelity  training  simulators,  such  as  CCTT 
Ml  or  M2  vehicle  simulators.  A  third  approach  that  incurs  significant  development  cost,  but 
lower  per  unit  acquisition  costs,  is  to  develop  medium-fidelity  reconfigurable  simulators  for 
classes  of  vehicles,  i.e.,  one  or  more  types  for  ground  vehicles,  one  or  more  types  for  aircraft.  A 
fourth  approach  is  to  procure  lower  fidelity  COTS  reconfigurable  simulators,  such  as  MAK  Dial- 
a-Tank.  This  can  become  even  lower  cost  if  the  software  can  be  adapted  by  the  vendor  to  run  on 
PCs,  instead  of  workstation  class  machines.  A  fifth  approach  is  to  utilize  SAFs  and  CGFs  to 
represent  additional  forces. 

The  best  approach  for  the  Core  DIS  Facilities  (CDF)  and  the  battle  laboratories  is  to  determine 
how  many  and  what  types  of  simulators  will  suffice  for  the  majority  of  their  needs.  This  will 
allow  economical  tradeoffs  to  be  made  to  meet  those  needs  through  combinations  of  cases  1-5. 

STRICOM’s  role  could  be  to  work  with  each  CDF  and  battle  laboratory  to  determine  their 
individual  requirements,  and  then  define  an  optimal  consolidated  approach.  If  developing  one  or 
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more  classes  of  reconfigurable  simulators  is  an  economical  alternative,  STRICOM  could  be  the 
leader  in  developing  those  simulators. 

5.5.7  Tools 

There  are  a  number  of  areas  where  tools  are  required  and  where  STRICOM  could  invest  in 
creating  tools.  Four  fundamental  areas  include  tools  for  architecture,  tools  for  an  exercise  starter 
kit ,  tools  for  exercise  monitoring,  and  tools  for  after  action  reviews  and  post  test  analysis. 

STRICOM  has  invested  heavily  in  the  development  and  fielding  of  the  HLA.  This  investment 
must  continue  to  ensure  a  common  architecture  is  achieved.  Where  possible,  tools  need  to  be 
developed  that  would  help  make  HLA  compliance  easier.  This  would  have  broad  reaching 
effects,  because  the  community  could  used  a  tool  set  like  this  to  help  transition  legacy 
simulations  to  HLA  compliance.  Continued  development  of  tools  is  necessary  to  ensure  that  a 
common  interchange  between  simulations  is  achieved.  The  SEDRIS  program  has  been  chartered 
to  do  this,  but,  requires,  as  with  the  HLA,  continued  funding  and  the  directed  use  of  SEDRIS  as 
the  common  interchange  format. 

A  starter  kit  is  required  for  use  in  exercise  simulations.  Oftentimes,  these  simulations  require  an 
expert  user.  If  a  starter  kit  is  developed  for  simulations,  then  the  user  does  not  have  to  be  an 
expert  in  any  one  simulation,  but  rather  an  expert  in  the  training  goal  of  the  simulation. 

As  the  simulation  is  being  conducted,  there  needs  to  be  a  way  to  gather  data  or  monitor  the 
simulation.  This  can  be  accomplished  by  having  a  “stealth”  program  running  in  the  background, 
while  the  simulation  is  operating.  Monitoring  allows  the  user  to  know  if  the  goal  is  being  met  or 
allows  the  user  to  terminate  or  restart  if  it  is  not.  Also,  monitoring  allows  for  the  gathering  of 
data  for  after  action  review  and  post  test  analysis.  Tools  for  assessing  the  success  of  the 
simulation  are  essential  to  objectively  evaluate  how  well  the  simulation  accomplished  the 
training  objective.  When  creating  a  new  model  or  an  extension  of  one,  there  needs  to  be  a  way  to 
test  its  success.  Often  this  is  accomplished  by  regression  testing  -  an  authoritative  data  set  is 
created  and  the  new  version  is  compared  against  the  previous  version.  This  type  of  testing 
should  be  accomplished  for  simulations. 

STRICOM’s  role  can  be  in  the  four  areas  above.  By  investing  in  architectures,  starter  kits, 
monitoring  tools,  and  post  test  analysis  tools,  STRICOM  could  lead  in  simulation  technology 
from  the  development  to  the  execution  to  the  review  of  a  simulation. 
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6.  SUMMARY  AND  CONCLUSIONS 

There  were  two  contractual  objectives  for  this  effort.  The  first  was  to  provide  analysis  and  data 
for  a  plan  to  guide  the  direction  of  the  synthetic  environment  (SE)  development  through  the 
POM  98-03.  The  second  was  to  provide  STRICOM  with  a  mid  and  long-range,  high  level 
strategic  plan  for  synthetic  environment  development  and  execution. 

Research  and  data  gathering  were  conducted  to  help  identify  the  Army's  major  SE  needs  for  FY 
98-03.  That  information  was  analyzed,  consolidated,  and  prioritized  to  the  extent  possible. 
Completion  of  that  activity  fulfilled  the  first  objective.  Plans  were  then  generated  for  how  to 
meet  each  of  the  identified  major  SE  needs.  These  plans  are  documented  in  this  report  and  are 
also  summarized  in  a  companion  viewgraph  presentation.  Completion  of  that  activity  fulfilled 
the  second  objective. 

The  approach  taken  was  determine  the  synthetic  environment  status  and  needs  from 

•  DoD  and  U.S.  Army  M&S  policies,  master  plans,  investment  plans,  and  vision  statements 

•  Interviews  with  a  wide  variety  of  senior  DoD  and  U.S.  Army  officials  who  are 
knowledgeable  about  and  involved  in  various  aspects  of  M&S  policy,  oversight, 
specification,  development,  and  use 

•  Other  M&S  professionals  identified  through  research  documents,  reports,  and  referrals 

The  inputs  from  these  sources  were  consolidated  into  categories  of  issues.  In  parallel,  enabling 
technologies  were  identified  that  can  be  applied  toward  solving  the  issues. 

Seven  categories  of  SE  issues  were  identified  and  prioritized.  The  top  category  was  synthetic 
natural  environment  issues,  especially  problems  relating  to  building  and  using  terrain  databases. 
The  need  for  better  representation  of  the  behaviors  of  individuals,  vehicles  with  crews,  units,  and 
commanders  and  their  staffs  was  the  number  two  category.  The  third  category  was  the  need  for 
better  interoperability  between  simulators.  Fourth  was  the  need  for  multipurpose,  reconfigurable 
simulators.  Better  communications  network  models,  and  interfacing  between  C4I  systems  and 
the  SE  were  fifth.  Sixth  was  the  need  for  more  entities,  to  simulate  larger  fights  between  more 
diverse  units.  The  remaining  category  was  tools  to  make  it  faster  and  easier  to  build  the  SE, 
design  and  set  up  experiments,  collect  data,  and  analyze  results. 

Eight  categories  of  enabling  technologies  were  identified  as  being  particularly  relevant  to 
developing  an  improved  SE.  They  were  architectures,  computers,  display  devices,  display 
generators,  man  machine  interface  devices,  networks,  software,  and  tools. 

Execution  plans  were  defined  and  documented  for  applying  each  enabling  technology  toward 
solving  the  SE  issues.  To  effectively  implement  these  plans  probably  requires  a  staff  of  technical 
experts  who  report  to  a  manager  who  is  above  the  Program  Managers.  Someone  at  that  level  is 
needed  to  make  and  enforce  decisions  that  may  impact  one  program  negatively,  but  are  best  for 
the  programs  as  a  whole. 

Execution  plans  were  defined  and  documented  for  addressing  each  of  the  SE  issues. 
Implementing  these  plans  must  be  accomplished  within  the  business  environment  that 
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STRICOM  operates.  This  will  involve  tradeoffs  among  the  priority  assigned  by  higher  level 
commanders,  the  estimated  cost,  funding  availability,  the  potential  benefit,  the  urgency  of  the 
time  frame,  and  the  development  risk. 

The  existence  of  these  SE  issues  presents  an  opportunity  for  STRICOM  to  provide  the  leadership 
to  solve  them  for  the  benefit  of  the  Army  M&S  community.  To  accomplish  this,  STRICOM  must 
be  address  five  issues: 

1 .  Implementing  the  solutions  will  require  an  appropriate  pool  of  skilled  technical  people. 

When  there  are  identified  solution  approaches,  the  technical  risk  is  low. 

2.  Funding  must  be  found  to  implement  each  solution.  Since  the  problems  needing  to  be  solved 
span  all  three  domains,  the  possibility  exists  to  solicit  and  pool  resources  from  a  number  of 
organizations.  Also,  a  pricing  strategy  is  needed  that  allows  STRICOM  to  earn  profits  on  the 
programs  it  executes.  This  profit  would  become  working  capital  and  investment  capital.  This 
is  a  normal  practice  in  all  businesses. 

3.  An  organizational  structure  is  needed  within  STRICOM  that  will  encourage,  facilitate,  and 
when  necessary  enforce  cooperative  developments  and  reuse  across  its  projects. 

4.  A  contractual  mechanism  is  needed  between  STRICOM  and  the  program  funding 
organizations  that  will  allow  STRICOM  to  earn,  use,  and  invest  profits. 

5.  Develop  strategic  alliances  with  key  government  and  industry  organizations. 

A  broader  leadership  opportunity  would  be  to  move  beyond  a  focus  on  training  simulators  and 
seek  to  provide  a  common  SE  and  common  applications  across  all  three  domains:  ACR,  RDA, 
and  TEMO.  The  broadest  leadership  opportunity  is  to  provide  well-organized,  high  quality 
leadership  to  the  entire  M&S  community,  and  target  becoming  the  Simulation  Center  for  the 
Army. 
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APPENDIX  A 

LETTER  AND  SURVEY  QUESTIONS 
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SURVEY  QUESTIONS 


1 .  Where  do  you  think  the  Army  should  get  to  in  Models  and  Simulations  (M&S)  capability 
over  the  next  five  years? 

2.  What  can  STRICOM  do  in  the  area  of  Synthetic  Environments  (SE)  that  would  most  benefit 
your  organization  or  program?  In  what  time  frame  do  you  need  it? 

3.  What  do  you  see  as  the  top  breakthrough  opportunities  in  SE?  The  key  enabling  technologies 
for  those  breakthroughs? 

4.  For  which  SE  related  items  would  you  strongly  recommend  that  development  continue  or 
accelerate? 


5.  What  do  you  think  are  the  SE  related  problems  that  most  need  addressing?  In  what  time 
frame  are  solutions  needed? 


6.  For  which  SE  related  items  would  you  recommend  that  current  development  be  halted  or 
redirected? 


7.  What  other  input  can  you  provide  that  would  help  in  formulating  a  Synthetic  Environment 
Strategic  Plan  for  STRICOM? 
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APPENDIX  B 

CONTACT  LIST 
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CONTACT  LIST 

Allison,  Julie  Standards  Category  Coordinator  -  Mobilization  301-295-1588 

Director,  USA  CAA  ATTN:  CSCA-OS 
8120  Woodmont  Ave 
Bethesda,  MD  2081-2797 

Bauman,  Michael  F.  Director,  Attn:  ATRC  913-684-5132 

US  Army  TRADOC  Analysis  Command 
Ft.  Leavenworth,  KS  66027-5200 

Bernay,  Dorothy  Standards  Category  Coordinator-  Cost  Representation  703-681-3347 

Dir,  USAA  Cost  &  Economic  Analysis  Center 
ATTN:  SFFM-CA-PA  Rm.  327,  Nassif  Building 
561 1  Columbia  Pike 
Falls  Church,  VA  22041-5050 

Blair,  Alex  Standards  Category  Coordinator  -  Logistics  804-734-0322 

USACASCOM  ATTN:  ATLC-CAT 
Fort  Lee,  VA  23801-6000 

Bradley,  Brad  Standards  Category  Coordinator  -  Object  Management  410-278-4066 

Director  AMSAA  ATTN:  AMXSY-CD 
392  Hopkins  Road 

Aberdeen  Proving  Ground,  MD  21005-5071 

Brewer,  Jesse  Standards  Category  Coordinator  -  Data  410-278-2090 

Director,  AMSAA  ATTN:  AMXSY-AP 
392  Hopkins  Road 

Aberdeen  Proving  Ground,  MD  21005-5071 

Budge,  Larry  (MG)  (R)  ARPA,  ATSO  Div,  Rm.  877  703-696-2298 

3701  N.  Fairfax  Dr. 

Alexandria,  VA  22203-0000 

Bullock,  Brad  Standards  Category  Coordinator  -  Move  601-634-3372 

ATTN:  CEWES-GM-K 
3909  Halls  Ferry  Road 
Vicksburg,  MS  39181-6199 

Caldwell,  Doug  Rapid  Construction  of  Virtual  Worlds,  USATEC  703-428-6719 

Coleman,  Gary  Air  Manuever  Battle  Lab  334-255-3485 

Attn:  ATZQ-CDB,  Bldg  5000 
Ft.  Rucker,  AL  36362-5000 

Fallin,  Herb  (Dr)  HQDA  (SARD-ZD)  Asst.  Secretary  of  the  Army  for  RDA  703-697-2653 

103  Army  Pentagon 
Washington  D.C.,  20310-0103 

Findley,  B.F.  (COL)  SETA-BDM  (USATEC)  703-351-6925 

Gardner,  Nancy  Terrain  Data  Base  Generation  and  Development  (USATEC)  703-428-6954 
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Goodman,  Glenn  C.  SETA-BDM  (DARPA) 

Gunzelman.  Karl  (COL)  Commandant  US  Army  Armor  Center 

Attn:  ATZK-MW 

Ft.  Knox,  KY  40121-5000 

Haes,  Steve  SETA  BDM  (USATEC) 

Hardin(  COL).  Attn:  SFUS-MIS 

1725  Jefferson  Davis  Highway  Suite  808 
Arlington,  VA  22202 

Harkrider,  Susan  Standards  and  Category  Coordinator  -  Architecture 

USA  STRICOM  ATTN:  AMSTI-ET 
12350  Research  Pkwy 
Orlando,  FL  32826-3276 


703-428-6501 

502-624-7809 

703-428-6702 

703-601-0012 

407-384-3926 


Huntley,  Jack  Synthetic  Environments  Evaluation  and  Demonstration  Site  703-428-6651 

USATEC 


Inge,  Joseph  (BG)  Deputy  Commandant  913-684-3443 

US  Army  Command  and  General  Staff  College 

1  Reynolds  Avenue 

Ft.  Leavenworth,  KS  66027-1352 

Koklauner,  Karl  Program  Manager,  USATEC  703-428-6845 

USATEC  Synthetic  Environments 

Kunkel,  Burt  Standards  Category  Coordinator  -  C3  Systems  706-791-1977 

Representation 

Modeling  &  Simulation  Branch  Concepts  and  Architecture  Div 
Directorate  of  Combat  Developments 
Ft  Gordon,  GA  30905-5090 


Larocque,  Robert  (Dr)  Attn:  ATZL-CTS 

Director, National  Simulation  Center 
246  Kearny  Avenue 
Ft  Leavenworth,  KS  66027-7000 

Logan,  Paul  Rapid  Construction  of  Virtual  Worlds  (USATEC) 

Lukes,  George  Program  Manager 

DARPA  Synthetic  Environments 

Lunceford,  Dell  3701  N. Fairfax  Dr. 

Arlington,  VA  22203 


913-684-8101 


703-428-6803 

703-696-2364 

703-696-2238 


Mehaffey,  Michael  (COL)  HQ  TRADDOC  ,  Office  of  the  Deputy  CIS  for  Combat  Dev  757-728-5850 

Battle  Lab,  Integration,  Technology  &  Concepts  Directorate 

ATCD-B  Building  163 

Ft.  Monroe,  VA  23651-5000 


Miller,  Duncan  (Dr)  MIT  Lncoln  Lab 


781-981-7452 
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Mullane,  Kevin 

Integrated  CGF  Terrain  Data  Base  Representation  in  DIS 
USATEC 

Neff,  Kimberly 

SETA  BDM  USATEC 

Oscar,  Ken  (Dr) 

Assistant  Secretary  of  the  Army,  RDA 

Attn:  SARD-ZA  Rm.  2E-672 

Army  Pentagon,  Washington  D.C.  20310-0103 

Pickett,  Kent 

Director,  US  Army  TRADDOC  Analysis  Command 

255  Sedgwick  Avenue,  Bldg  314 

Ft.  Leavenworth,  KS  66027-5200 

Powell  (Mr) 

CDR,  USAIC  &  FH 

Attn:  ATZS-BL 

Ft.  Huachuka,  AZ  85613-6000 

Reddy,  Robert  (COL) 

Cmdr  Army  Training  Support  Center  (ATSC) 

Bldg  1721 

FtEustis,  VA  23604-5166 

703-428-6792 

703-428-6702 

703-695-6153 


913-684-4595 


502-533-4661 


757-878-4107 


Reed,  Marshall  (COL)  US  ARMY  Battle  Command  Battle  Lab 

415  Sherman  Avenue 

Ft.  Leavenworth,  KS  66027-5300 

Roos,  Mas  Rapid  Extraction  of  Digital  Elevation  and  Feature  Data 

Sutton,  Melvin  Standards  Category  Coordinator  -  Deployment/Redeployment  757-599-1638 

Director,  MTMC,  Transportation  Engineering  Agency 
ATTN:  MTTE-SIT 

720  Thimble  Shoals  Blvd  Suite  130 
Newport  News,  VA  23606 
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GLOSSARY  OF  ACRONYMS 
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GLOSSARY  OF  ACRONYMS 


ACR 

Advanced  Concepts  and  Requirements 

ALSP 

Aggregate  Level  Simulations  Protocol 

AMG 

Architecture  Management  Group 

AMSEC 

Army  Model  and  Simulation  Executive  Council 

AMSO 

Army  Model  and  Simulation  Office 

API 

Application  Program  Interface 

AU 

Adapter  Unit 

BBS 

Brigade/Battalion  Battle  Simulation 

CCTT 

Close  Combat  Tactical  Trainer 

CECOM 

Communications  and  Electronics  Command 

C4I 

Command,  Control,  Communications,  Computers,  and 
Intelligence 

CGF 

Computer  Generated  Force 

CIG 

Computer  Image  Generator 

COTS 

Commercial-off-the-Shelf 

CPAF 

Cost  Plus  Award  Fee 

CRT 

Cathode  Ray  Tube 

DIS 

Distributed  Interactive  Simulation 

DMSO 

Defense  Model  and  Simulation  Office 

DoD 

Department  of  Defense 

EXCIMS 

Executive  Council  on  Modeling  and  Simulation 

GUI 

Graphical  User  Interface 

HLA 

High  Level  Architecture 

I/O 

Input/Output 

JSIMS 

Joint  Simulation  System 

JSTARS 

Joint  Surveillance  Target  Attack  Radar  System 

JTA 

Joint  Technical  Architecture 

JWARS 

Joint  Warfare  System 

LAN 

Local  Area  Network 

LCD 

Liquid  Crystal  Display 

ModSAF 

Modular  Semi-Automated  Forces 

MRCI 

Modular  Reconfigurable  C4I  Interface 

M&S 

Models  and  Simulation 

MSO 

Mission  Space  Objects 

OPFOR 

Opposing  Forces 

OPSIN 

Operational  State  Interpreter 

OSD 

Office  of  the  Secretary  of  Defense 

PM 

Program  Manager 

RDA 

Research,  Development  and  Acquisition 

RF 

Radio  Frequency 
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